Blog Post: Beating std::visit Without Really Trying
paolo.invernizzi at gmail.com
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
> 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