D has become unbearable and it needs to stop

[Steven Schveighoffer]

On 6/8/23 11:21 AM, Adam D Ruppe wrote:
> On Thursday, 8 June 2023 at 15:00:04 UTC, Steven Schveighoffer wrote:
>> In this case, `__traits(getAttributes)` was *wrong*, so a bug is being 
>> fixed. How do we fix bugs like this without using deprecations and 
>> eventual removal?
> 
> The problem is that there is no easy migration path for the cases where 
> it actually did work just fine. The update required an extra static if 
> branch added to each use for a generic loop.

You mean, it happened to work because of the ordering of the overloads? 
This is the nature of things that do something incorrect in the face of 
ambiguity.

This very much reminds me of the cycle detection problems I fixed. 
Cycles wouldn't get detected, because the algorithm was flawed. Fix the 
algorithm, and now "working" code breaks because there actually is a 
cycle. What do we do about it?

The answer at the time was to introduce a ridiculous deprecation system, 
where I implemented both the correct algorithm and the incorrect 
algorithm, and ran *both*. Then if they disagreed, still allow it and 
print a deprecation message.

In my estimation that is what is happening here -- you are relying on a 
faulty implementation, and that reliance is being deprecated.

> 
> Moreover, a loop over overloads *still* required an additional 
> getOverload since the deprecation message triggers in cases when it 
> shouldn't have!
> 
> foreach(idx, overload; AliasSeq!(__traits(getOverloads, Module, 
> memberName))) static if(.isScriptable!
>          (__traits(getAttributes, __traits(getOverloads, Module, 
> memberName)[idx]))()) { // lol  i have to do the second getOverload to 
> stop the compiler from deprecating

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

And... bug just filed a few days ago.

https://issues.dlang.org/show_bug.cgi?id=23966

-Steve