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