On 10/5/19 7:58 AM, Seb wrote:
> On Saturday, 5 October 2019 at 06:40:35 UTC, Arun Chandrasekaran wrote:
>> On Saturday, 5 October 2019 at 02:59:58 UTC, Paul Backus wrote:
>>> I was curious how C++17's std::variant compared to the options we have in D, like Algebraic and SumType, so I did a simple comparison of the generated assembly for each of them. You can read about it at the link below. And as you can probably guess from the title, D comes out ahead, in the end.
>>>
>>> https://pbackus.github.io/blog/beating-stdvisit-without-really-trying.html 
>>>
>>>
>>> This is my first attempt at sharing something like this, so any comment or feedback is very much appreciated!
>>
>> Good one. Any plans to push SumType as a replacement of Phobo's Algebraic?
> 
> Phobos is essentially dead/frozen (feature-wise). Though if someone ever manages to get v2 of the ground, SumType would be the obvious choice.

I think we'd do good to choose words with care. An extraordinary assertion, however odd and unjustified, may go by chance unchallenged and if repeated enough soon starts passing as the accepted truth. This is very damaging, regardless of how well it was intended initially, goodwill I have no doubt about. To set the record straight: Phobos is not dead and is not frozen feature-wise. It is and has always been open to adding new functionality, and of course to improve implementation of existing functionality.

Variant's design and implementation are very, very, very old. We're talking 15 years. It is literally the first generic design I've ever done in D, and at the time getting it (or anything nontrivial) to work was a large challenge. At that time only the most basic examples worked for any template-related feature. The code also predates most of the CTFE niceties we now take for granted, static foreach included. Not to mention, I'd be the first to say I engineered the thing poorly. A radical simplification is definitely possible and desirable.

> Anyhow, currently we would have to name it differently (e.g. dts - https://github.com/wilzbach/dts). Maybe the upcoming SAoC project will change this and allow multiple versions of a library to co-exist in a binary.

Adding it as a new facility is a possibility, but only if the challenges of keeping the existing interface are too large.

I wonder about the generated Assembly:
In Rust if u add #[repr(usize)] to the enum the generated code as only two lines.


In D, Look like the first assembly lines are checking for errors(or out of bounds index?).
But why if this is a final switch? (also assert(0); at the end don´t help )

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.

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.

I'm sorry, my choice of words wasn't wise (and I certainly didn't mean it in a negative way). Phobos is amazing and stable, but exactly because of these attributes there isn't much active development happening. Stability implies no breaking changes which is **very very good** because it allows the ecosystem to thrive (and not break builds because Algebraic was swapped against SumType).

Below I have listed a summary of all announced changes in Phobos since the beginning of this year (six releases, 2.088 - 2.083). This lists only the announced changes (and there are more bug fixes), but in total we're looking at one new function (getAvailableDiskSpace), two new overloads (schwarzSort, unpredictableSeed) over these six releases. That's what I was referring to.
For comparison: in the meantime about 200 new Dub packages have been added [1, 2] and in total about 600 Dub packages have been updated [3].


2.088:
- std.array.Appender and RefAppender: use .opSlice() instead of data()
- ErrnoException.errno is now nothrow pure @nogc @safe
- Nullable alias get this has been deprecated
- Added the std.file.getAvailableDiskSpace functionality.
- Allow std.json to overlook trailing comma

2.087:
- Added a table of control characters in ASCII table
- Count processors via sched_getaffinity on Linux
- Add overload std.algorithm.sorting.schwartzSort!(alias transform, SwapStrategy ss, R)
- Phobos is now compiled with -preview=dip1000

2.086:
- Fixed comparison bug in std.algorithm.comparison.levenshteinDistance
- std.experimental.all has been moved to std

2.085: (no changes)

2.084:
- Add overload std.random.unpredictableSeed!UIntType

2.083: (no changes)

See more at [4].

[1] https://web.archive.org/web/20181229043818/http://code.dlang.org/
[2] https://code.dlang.org/
[3] https://code.dlang.org/?sort=updated&category=&skip=500&limit=100
[4] https://dlang.org/changelog/index.html

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

I'm sorry and while I like this effort, I don't expect it to help because it does break the world.
AFAICT the only way to avoid breaking the world when removing autodecode is to ship a new/different version of Phobos _together_ with the current one, s.t. it can be opted-in by users.

Anyhow, I think Andrei summarized it better a few months ago:

> The time is ripe for std.v2 [https://forum.dlang.org/post/q7j3s0$15n7$1@digitalmars.com]

My earlier post tried to point out that SumType is an excellent candidate for v2.

On Sunday, 6 October 2019 at 03:47:25 UTC, Seb wrote:
> My earlier post tried to point out that SumType is an excellent candidate for v2.

Sorry, Seb, but I don't get this. There's no reason to wait for a v2 to introduce a new SumType symbol that outperforms the old Variant (assuming it's not possible to just rewrite the latter implementation under the hood without changing behaviour).

On the contrary, the best way to do a v2 is likely to be that all or most of the stuff we want in it is already there and has been battle tested in the wild.

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:
https://www.reddit.com/r/programming/comments/ddi5wb/comment/f2iow4u

The commenter suggests that's because Rust bakes the functionality into the compiler instead of making it a library type. @Walter, @Andrei, that might be an interesting data point for the question of what should have compiler vs. library support?

On Sunday, 6 October 2019 at 00:52:38 UTC, Andrei Alexandrescu wrote:
>> Anyhow, currently we would have to name it differently (e.g. dts - https://github.com/wilzbach/dts). Maybe the upcoming SAoC project will change this and allow multiple versions of a library to co-exist in a binary.
>
> Adding it as a new facility is a possibility, but only if the challenges of keeping the existing interface are too large.

I just want to chime in as a returning D user, who stumbled upon Nullable, Typedef and Algebraic.

I think is is important to have high quality and well supported versions of these kinds of type constructors in the standard library, because to really shine support for them has to be pervasive. I could roll my own (or use some package from code.dlang.org), but one of the key features have to be that they 'just work'. I want to std.conv.to them [1], use them in a json serialization library out of the box, etc, etc.

[1] https://issues.dlang.org/show_bug.cgi?id=11704

On Sunday, 6 October 2019 at 07:16:03 UTC, Joseph Rushton Wakeling wrote:
> On Sunday, 6 October 2019 at 03:47:25 UTC, Seb wrote:
>> My earlier post tried to point out that SumType is an excellent candidate for v2.
>
> Sorry, Seb, but I don't get this. There's no reason to wait for a v2 to introduce a new SumType symbol that outperforms the old Variant (assuming it's not possible to just rewrite the latter implementation under the hood without changing behaviour).

Well, my guess it will be similar to that one time when `Option` (https://github.com/dlang/phobos/pull/3915) was rejected because it was only slightly better than `only` or the other time when it was attempted to improve `Nullable` (e.g. https://github.com/dlang/phobos/pull/6253)?
Alternatively, there is also the route pioneered by std.typecons.wrap whose improvements are - after more than four years - still stuck in std.experimental.wrap (https://github.com/dlang/phobos/pull/2945, https://dlang.org/phobos/std_experimental_typecons.html#.wrap).


> On the contrary, the best way to do a v2 is likely to be that all or most of the stuff we want in it is already there and has been battle tested in the wild.

A standard library is _not_ supposed to be a place where actual battle-testing happens. It's where things move when they have been tested and no longer change. This "readiness" condition is one of the reasons why only a single function has been added to Phobos in 2019 so far.

Please don't misunderstand me: I would love to see SumType in Phobos. There are tons of other great modules that would make a great base as well, e.g. http://rumbu13.github.io/decimal/doc/decimal.html, https://code.dlang.org/packages/optional, or https://github.com/dlang-community/std_data_json etc.
I plainly doubt that we will ever see them in the current Phobos.

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

On Sunday, 6 October 2019 at 08:27:35 UTC, Seb wrote:
> Well, my guess it will be similar [...]

If you're not the one making those decisions it may be better not to prejudge them. A significant performance improvement is a different beast to moderate API/usability improvements.

> A standard library is _not_ supposed to be a place where actual battle-testing happens. It's where things move when they have been tested and no longer change.

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

It's much better to get newer and apparently better designs exposed to this level of scrutiny _before_ making them the only option in a new major release. That way you are much less likely to get hit by a showstopper edge case that no one anticipated.