wt., 10 lut 2026 o 13:55 Alejandro Colomar
<une+cxx_std-proposals_at_[hidden]> napisał(a):
>
> Hi Marcin,
>
> On 2026-02-10T13:27:42+0100, Marcin Jaczewski wrote:
> > wt., 10 lut 2026 o 13:03 Alejandro Colomar
> > <une+cxx_std-proposals_at_[hidden]> napisał(a):
> > >
> > > Hi Marcin,
> > >
> > > On 2026-02-10T10:56:23+0100, Marcin Jaczewski via Std-Proposals wrote:
> > > > niedz., 8 lut 2026 o 19:34 Arthur O'Dwyer via Std-Proposals
> > > > <std-proposals_at_[hidden]> napisał(a):
> > > [...]
> > > > >> How does this use of an attribute fit the idea that attributes
> > > > >> have optional semantics, given that the program will be ill-formed
> > > > >> without the attribute present?
> > > > >
> > > > >
> > > > > It doesn't. Nobody likes the "ignorable attribute rule." See for example
> > > >
> > > > False, I like how they are handled :P
> > > > Only problem is people try sove in things that they should not.
> > >
> > > How do you feel about this?
> > >
> > > alx_at_devuan:~/tmp$ cat nodiscard.c++
> > > [[nodiscard]] int f(void);
> > >
> > > int
> > > main(void)
> > > {
> > > typeof(int (void) ) *fp1;
> > > typeof(int (void)[[nodiscard]]) *fp2;
> > >
> > > fp1 = &f; // I would expect a diagnostic here.
> > > fp1();
> > >
> > > fp2 = &f;
> > > fp2();
> > > }
> > > alx_at_devuan:~/tmp$ g++ -S -Wall -Wextra nodiscard.c++
> > > nodiscard.c++: In function ‘int main()’:
> > > nodiscard.c++:7:38: warning: ‘nodiscard’ attribute can only be applied to functions or to class or enumeration types [-Wattributes]
> > > 7 | typeof(int (void)[[nodiscard]]) *fp2;
> > > | ^
> > >
> > >
> >
> > This is fine, the compiler sees that he can't fulfil his job and gives
> > you a warning.
> > This could be done by IDE or some external tool too.
> > I recall the goal was if you use attributes correctly then it does not
> > matter if the compiler recognizes it or not.
> > Like `[noreturn]` for correct code it does not matter if the compiler
> > generates some dead code as you can't observe it.
> > But for wrong code then you see diffrent results on diffrent
> > compilers. And I think this is acceptable.
>
> No, that was not the point. The point is that the conversion in
> fp1 = &f;
> discards an attribute from the function type, and thus results in calls
> through that function pointer to not have a diagnostic when the return
> value is discarded. This is a hole in the rules.
>
> And the diagnostic you see in fp2 is in fact another hint that the
> design of [[nodiscard]] was bogus. That code should be accepted, and it
> should be the only way of storing a function pointer that holds &f. If
> that's not accepted, there is no way of using [[nodiscard]] safely.
>

But what does this have to do with ignorability of attributes?
It's possible that you could not add the "not-ignorable" attribute there anyway.
```
std::is_same<int, [[foo]] int>
```
how C++ should handle it? even in case where it can't ignore this attribute.

Only solution I see is that `fp1` itself should have `[[nodiscard]]`,
and this could be still ignorable.

>
> Cheers,
> Alex
>
> >
> > > >
> > > > First of all, non-ignorable attributes should be explicit and ilformed
> > > > even if the compiler does not know them even in C++11.
> > >
> > > Agree.
> > >
> > > > I suggested adding the prefix `!!` for one like this, this could be
> > > > any symbol that makes C++11 reject this code and make this feature
> > > > backward and forward compatible.
> > >
> > > We already have non-ignorable attributes: scoped ones. This means that
> > > [[::attr]] is already the syntax for non-ignorable attributes. It only
> > > needs to be specified in the standard that the empty prefix is for the
> > > standard.
> > >
> > > > This will make a clear distinction between these two versions.
> > >
> > >
> > > Have a lovely day!
> > > Alex
> > >
> > > --
> > > <https://www.alejandro-colomar.es>
>
> --
> <https://www.alejandro-colomar.es>