On Sunday, 6 October 2019 at 02:33:15 UTC, Walter Bright wrote:
> On 10/5/2019 6:58 AM, Seb wrote:
>> Phobos is essentially dead/frozen (feature-wise).
> I beg to disagree. A couple cases in point:
>
>     https://github.com/dlang/phobos/pull/7211
>
> which is a re-imagining, rethinking of hexString.
>
> and:
>
>     https://github.com/dlang/phobos/pull/7130
>     https://github.com/dlang/phobos/pull/7144
>
> both of which work to remove autodecode from Phobos. 7130 in particular can use some help with anyone who wants to help drive this forward.

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:

   https://github.com/dlang/phobos/pull/6730

Frankly speaking, the actual situation it's a little discouraging...

On Sunday, 6 October 2019 at 07:18:37 UTC, Joseph Rushton Wakeling wrote:
> Speaking of performance, I was intrigued by the Reddit response noting that Rust can go one better by eliminating the error path at compile time:

D can eliminate error paths at compile time too, e.g. static assert - which can be used to create all kinds of new useful errors. So I am guessing this is just a case of the code needing a lil tweak or the compiler being conservative and putting the code in even though it is never supposed to happen (like final switch keeps an error path because you can do like cast(some_enum) value_not_in_enum.... and then better to have the assertion failure than UB.)

On Sunday, 6 October 2019 at 08:31:20 UTC, Dennis wrote:
> On Sunday, 6 October 2019 at 00:58:17 UTC, SrMordred wrote:
>> But why if this is a final switch? (also assert(0); at the end don´t help )
>
> Because the optimization hasn't been implemented yet.
> https://issues.dlang.org/show_bug.cgi?id=13169

1) Nice to know that is possible.
2) 2014 ... ouch.

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:
> 
>     https://github.com/dlang/phobos/pull/6730
> 
> 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.

On Sunday, 6 October 2019 at 14:08:07 UTC, Adam D. Ruppe wrote:
> D can eliminate error paths at compile time too, e.g. static assert - which can be used to create all kinds of new useful errors. So I am guessing this is just a case of the code needing a lil tweak or the compiler being conservative and putting the code in even though it is never supposed to happen (like final switch keeps an error path because you can do like cast(some_enum) value_not_in_enum.... and then better to have the assertion failure than UB.)

Good to hear. I confess I was a bit mystified about why it should be an issue for D or why compiler vs. library implementation should make a difference to the ability to eliminate the error path (I infer from your remarks that it shouldn't, in principle).

I'm not fluent in assembly so, leaving the error path aside, I wasn't sure how to interpret the "main path" assembly from the D and Rust code, and whether they were practically equivalent (clearly the assembly posted looked different). Can anyone offer any interpretation there?

On Sunday, 6 October 2019 at 21:49:59 UTC, Joseph Rushton Wakeling wrote:
> I'm not fluent in assembly so, leaving the error path aside, I wasn't sure how to interpret the "main path" assembly from the D and Rust code, and whether they were practically equivalent (clearly the assembly posted looked different). Can anyone offer any interpretation there?

Both the D-with-SumType and Rust versions optimize the main path of the function down to a single array lookup. The reason they look different is that the assembly for the D version uses AT&T syntax (which is the default for GNU tools like objdump), and the assembly for the Rust version uses Intel syntax.

On 10/6/19 3:09 AM, Joseph Rushton Wakeling wrote:
> You misunderstand what I mean by "battle-testing". Clearly designs should go through a high level of testing and usage before they go anywhere near the standard library. But the very fact of being placed in the standard library exposes them to orders of magnitude more usage, and hence gives a much stronger guarantee of establishing their correctness (or identifying their flaws).

Well also in the case of SumType there's not even much battle-testing. It's more of an implementation than a design. Take the existing variant, keep the interface, remove the cruft, put in the new nice code. Make it pass the unittests, and release. Of course it's an involved process, but definitely not more difficult than writing the new code to start with. The author receives credit as the primary author of the facility. It is wonderful service to the community - not only offers better speed for new code, but it instantly enhances speed of existing variant uses.

On Monday, 7 October 2019 at 01:09:34 UTC, Andrei Alexandrescu wrote:
> Well also in the case of SumType there's not even much battle-testing. It's more of an implementation than a design. Take the existing variant, keep the interface, remove the cruft, put in the new nice code. Make it pass the unittests, and release. Of course it's an involved process, but definitely not more difficult than writing the new code to start with. The author receives credit as the primary author of the facility. It is wonderful service to the community - not only offers better speed for new code, but it instantly enhances speed of existing variant uses.

Just to clarify: SumType isn't, and was never intended to be, a drop-in replacement for Algebraic. Their interfaces are similar enough that porting code from Algebraic to SumType shouldn't be too difficult, but even within the common subset, there are incompatibilities. For example, here's a post from an old sumtype announcement thread where I discuss the differences between SumType's `match` and Algebraic's `visit`:

https://forum.dlang.org/post/xipgrrfljdnyhrhnmsij@forum.dlang.org

If SumType is ever added to Phobos, it will have to be alongside Algebraic, as an alternative, not as a replacement.

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:
>> 
>>     https://github.com/dlang/phobos/pull/6730
>> 
>> 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

So:

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

On Monday, 7 October 2019 at 01:38:04 UTC, Paul Backus wrote:
> Just to clarify: SumType isn't, and was never intended to be, a drop-in replacement for Algebraic. Their interfaces are similar enough that porting code from Algebraic to SumType shouldn't be too difficult, but even within the common subset, there are incompatibilities. For example, here's a post from an old sumtype announcement thread where I discuss the differences between SumType's `match` and Algebraic's `visit`:
>
> https://forum.dlang.org/post/xipgrrfljdnyhrhnmsij@forum.dlang.org

I don't follow. The visit and match template signatures are identical, and from what you describe the SumType match implementation should support the same handler choices as visit, while allowing extra/more flexible choices.

Where's the breaking change? Are there selections of handlers that work for visit and don't work with match?