[PATCH] Decorate string_view members with nonnull attribute

[Jonathan Wakely]

On 14/06/18 20:27 +0300, Ville Voutilainen wrote:
>On 14 June 2018 at 20:21, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
>> On 14 June 2018 at 20:08, Jonathan Wakely <jwakely@redhat.com> wrote:
>>>> Oops, indeed. But for gnu-attributes, surely we can decide whatever we
>>>> want about what's
>>>> valid and what's not?
>>>
>>>
>>> We could say that #defining 'nonnull' and/or 'gnu' as a macro is
>>> undefined, but then programs that the standard says are valid would
>>> fail to compile, and we'd be a non-conforming implementation.
>>>
>>> We can use __attribute__(__nonnull__)) so that we accept those
>>> programs (and be a conforming implementation). Why would we choose to
>>> be non-conforming when we don't have to?
>>
>> I can read the specification liberally enough that it might give us
>> the freedom to disallow programs
>> that #define names that our implementation uses for vendor attributes.
>
>Namely "For an attribute-token (including an attribute-scoped-token)
>not specified in this document, the behavior is
>implementation-defined.", aka [dcl.attr.grammar]/6.

As I said on IRC, if the user does

#define gnu R"(
 ,= ,-_-. =.
 ((_/)o o(\_))
  `-'(. .)`-'
      \_/
)"

then the attribute-scoped-token isn't even valid, and so the behaviour
of the implementation-defined gnu::nonnull attribute doesn't matter.
The code doesn't contain such an attribute.

This seems like an unnecessary discussion: we should just use the
__attribute__ form instead.