D has become unbearable and it needs to stop

[Adam D Ruppe]

On Thursday, 8 June 2023 at 15:50:22 UTC, Steven Schveighoffer 
wrote:
> You mean, it happened to work because of the ordering of the 
> overloads?

Yes, attaching an attribute to the first overload worked well for 
a lot of cases and could have been specified to work. Or 
maximally, overload sets could be a well-defined concept in D and 
the symbol refers to them and then UDAs either don't attach to 
them or... something. Or, minimally, going from overload set to 
specific overload could have been made trivial and generic with 
other symbols that are not overload sets, so you can migrate by 
calling that instead of doing an extra branch externally.

> This is the nature of things that do something incorrect in the 
> face of ambiguity.

Technically, the spec is still ambiguous:

https://dlang.org/spec/traits.html#getAttributes

"Takes one argument, a symbol. Returns a sequence of all attached 
user-defined attributes. If no UDAs exist it will return an empty 
sequence "

It doesn't say anything about special treatment of overload sets, 
so it doing the same thing as the rest of the language - using 
the first one - is no more or less wrong than anything else.

In fact, it giving a deprecation is probably a violation of the 
spec...

These "bugs" ought to be defined in terms of the spec, and spec 
changes ought to be reviewed before merged.

> That seems like a bug in the deprecation. If you have the 
> overload, you shouldn't need a second getOverload.

Yes, indeed, the implementation of the deprecation is obviously 
broken.

Yet it shipped anyway.