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