Blog Post: Beating std::visit Without Really Trying

Paolo Invernizzi paolo.invernizzi at
Mon Oct 7 07:37:01 UTC 2019

On Sunday, 6 October 2019 at 19:58:04 UTC, Walter Bright wrote:
> On 10/6/2019 2:59 AM, Paolo Invernizzi wrote:
>> Well, so there's hope that _very little_ improvements will be 
>> merged, in a way or another? I mean, there's some sort of 
>> policy for things like that:
>> Frankly speaking, the actual situation it's a little 
>> discouraging...
> We want a much higher bar for merging things than historically. 
> A smaller, higher quality library is preferable to a kitchen 
> sink library.

The pull request I've shown is pretty simple:

- std.socket is ... well... not the best piece of code out there
- the `receive` method is usually in the _hot_ code path
- it's not marked @nogc, and actually it does not allocate


- adding @nogc will break derived classes that redefines the 
method (I still regret that the language was not shifted towards 
"final by default", years ago, as clearly that would be a *great* 
mitigation over that kind of problems)

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

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.

There's a number of recurring patterns of simple things to fix 
like the one above, with the same kind of problem to address. I 
humbly suggest the core team to just forge a general recipe for 
some of them, and stick with it, so that the number of the bar is 
less blurred. That scales, and encourage contribution.

So, what do you think about starting a first one bases on cases 
similar to the above?

More information about the Digitalmars-d-announce mailing list