Blog Post: Beating std::visit Without Really Trying

Atila Neves atila.neves at gmail.com
Wed Oct 16 15:01:17 UTC 2019


On Wednesday, 16 October 2019 at 12:32:28 UTC, Paolo Invernizzi 
wrote:
> On Wednesday, 16 October 2019 at 10:56:40 UTC, Atila Neves 
> wrote:
>> On Saturday, 12 October 2019 at 03:10:29 UTC, Walter Bright 
>> wrote:
>>> On 10/7/2019 12:37 AM, Paolo Invernizzi wrote:
>>>> - adding another method to a class, marked @nogc, and 
>>>> (maybe) deprecating the previous method is seen as 
>>>> 'annoying', also if it's a _clear_ improvement over the 
>>>> actual situation (you can write _better_ code with that in 
>>>> place compared to the actual situation, I mean)
>>>
>>> @nogc doesn't actually enable writing better code. It doesn't 
>>> change the generated code at all.
>>>
>>>
>>>> I'm on the same boat with you, regarding what you wrote, but 
>>>> ... I still don't understand the number printed on the bar 
>>>> level.
>>>
>>> Atila is in charge of this, and he is because he's shown 
>>> excellent judgement about these matters over the years.
>>
>> I think that I need to ruminate on Phobos v2.
>>
>> In the meanwhile, a much easier and shorter route to improving 
>> the D library ecosystem is to put something up on 
>> code.dlang.org, which requires no gatekeeping.
>
> While I agree on the ecosystem, the problem of keeping the 
> actual Phobos modules in a good shape still apply.
>
> 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. 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.

> I understand that "there's always something else better for the 
> language to do", but Phobos is the current "home sweet home" 
> for everyone approaching D, and it's the first library 
> inspected in details.

I understand that and sympathise.

> 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>...



More information about the Digitalmars-d-announce mailing list