DIP 1038: @nodiscard - Unofficial "post-final" review

[Paul Backus]

On Monday, 22 February 2021 at 20:12:05 UTC, Dukc wrote:
> Ok. Did a quick read and started to ponder one thing. The DIP 
> claims no breaking changes. If somebody is currently annotating 
> something with `@nodiscard` and using it so that the function 
> return value is discarded, it means that he must have a local 
> definition of `@nodiscard` and that will override the 
> `core.attribute` definition, and be no longer recognised by the 
> compiler. Is that correct?

Yes, the compiler will only recognize `core.attribute.nodiscard`.

> Even in that case, there is a theoretical possibility that the 
> user-defined `@nodiscard` is annotated in different module than 
> where it is used, and the user also happens to import 
> `core.attribute`. That would result in an ambiguous symbol.
>
> This is so far-fetched that it'll have no practical 
> signifiance, but if we're strict about mentioning all breaking 
> changes it goes there.

This can happen any time a new public symbol is added to a 
library. As far as I'm aware, adding a new public symbol is not 
normally considered a breaking change, so I don't think it's 
necessary to mention it in the DIP. Still, thanks for bringing it 
up--it never hurts to be thorough.