Blog Post: Beating std::visit Without Really Trying

[Paolo Invernizzi]

On Wednesday, 16 October 2019 at 15:01:17 UTC, Atila Neves wrote:

>> Please take a look at the cited pull request: it's a *trivial* 
>> Phobos patch, that can be added aside to the current 
>> implementation, blocked for months waiting for a _political_ 
>> decision.
>
> I don't think it's political: the change implies breakage for 
> downstream users who inherit from the class who might not even 
> care about @nogc.

The proposed solution is to "add" a new @nogc method, with the 
correct signature, so that if someone want to write application 
and care about @nogc and @safe can rely on the D standard library 
being complaint to that.

What's the problem with that, if not a _political_ one? We have a 
"wrong" signature, we don't break anything, but we add "correct" 
signature. That's what already was done in Mutex with 
lock_nothrow, but it's seen as "annoying to have to define/use 
alternate names for all the methods, though"

> This a technical point. The easiest way out in my opinion is to 
> to inherit from it yourself and mark `receive` @nogc, as was 
> suggested in the PR.

That's can't be done without a cast, so we need to rely on 
trusted, and we go again to the starting point, as stated the 
pull request.

>> It's simply embarrassing to explain to an external reviewer 
>> that a standard library method signature is inaccurate after 
>> 88 releases of version 2 of the language. And that yes, 
>> 'assumeNoGC' is needed, 'trust' that, and yes, an issue was 
>> filed along with a potential fix.
>
> Indeed. We're hardly alone in this: std::auto_ptr was/is an 
> embarassment in C++. Then there's std::vector<bool>...

And that's why I'm throwing a stone in the water: what's the 
'concrete' procedures that the gatekeepers have in mind to 
improve Phobos quality for cases like that?

Atila, that's really a _little_ change, if that can't be handled 
easily, what about handling _big_ changes?