Deprecating arithmetic on std::atomic<void*>

[Jonathan Wakely]

On 20/04/17 10:31 +0100, Jonathan Wakely wrote:
>On 20/04/17 11:24 +0200, Florian Weimer wrote:
>>On 04/20/2017 11:22 AM, Jonathan Wakely wrote:
>>>On 20/04/17 10:18 +0100, Jonathan Wakely wrote:
>>>>On 20/04/17 08:19 +0200, Florian Weimer wrote:
>>>>>On 04/19/2017 07:07 PM, Jonathan Wakely wrote:
>>>>>>I know it's a bit late, but I'd like to propose deprecating the
>>>>>>libstdc++ extension that allows arithmetic on std::atomic<void*>.
>>>>>>Currently we make it behave like arithmetic on void*, which is also a
>>>>>>GNU extension (https://gcc.gnu.org/onlinedocs/gcc/Pointer-Arith.html).
>>>>>>We also allow arithmetic on types such as std::atomic<void(*)()> which
>>>>>>is probably not useful (PR 69769).
>>>>>
>>>>>Why is it acceptable to have the extension for built-in types, 
>>>>>but not for library types wrapping them?  Why be inconsistent 
>>>>>about this?
>>>>
>>>>C++17 [atomic.types.pointer] paragraph 4 says:
>>>>
>>>>Requires: T shall be an object type, otherwise the program is
>>>>ill-formed. [Note: Pointer arithmetic on void* or function pointers
>>>>is ill-formed. — end note]
>>>>
>>>>That doesn't give us any leeway to support it.
>>
>>If we can ignore the Note, we can also ignore the requirement …
>>
>>>I suppose we could support it without -Wpedantic, although there's no
>>>way for the library to know if the front-end is being pedantic or not.
>>
>>Could you use SFINAE to detect whether the compiler supports 
>>arithmetic on void *?
>
>Probably. We'd have to move the relevant member functions into a new
>base class in order to make them conditionally disabled.

No, that doesn't work, because non-standard extensions are always
disabled in SFINAE contexts. It also wouldn't allow distinguishing
between -pedantic and -pedantic-errors.

Making the __atomic built-ins respect the pedantic flag is the right
way to handle it.

Or simply deprecate support for it in std::atomic. **If** the
extension for built-in types is useful then I can imagine it might be
useful to have it for std::atomic too, for a subset of the programs
relying on the original extension. But I'm unconvinced how useful
the original extension is. There are other ways to achieve it if
absolutely necessary, e.g. convert the void* to uintptr_t and perform
the arithmetic and use compare_exchange to store it back again.