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!

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!

I'm not sure if you're aware, but funnily enough, I also wrote an article[1] on std::variant vs. the D alternative that references Matt Kline's article on std::visit. It seems we're really making getting our money's worth from his article.

I really enjoyed this - I think you're right in that it comes down to the complexity of implementation, and I suspect that C++ forced the developers of std::variant to choose between a usable API (usable, not good) and performance.

I've been trying to communicate this major selling point of D to my coworkers, but it's a real uphill battle. I haven't even been able to convince them that built-in unit tests are a killer feature.

As an aside, I actively use your sumtype library and for the most part find it very nice to use. Thanks for the great work.

1.https://dlang.org/blog/2018/03/29/std-variant-is-everything-cool-about-d/

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?

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!

It'd be interesting if you could investigate the case of non-trivial lambdas, where inlining the lambdas is not profitable. Perhaps easiest if you call opaque (declaration-only) functions in the visit list.

Conclusion, performance-wise:
- SumType is great
- std::visit is OK'ish
- D Algebraic is terrible
Do you agree?

cheers,
  Johan

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!

getting typeinfo in D leads to a double indirection. Making a tagged union is clearly a better alternative and the results of SumType vs Algebraic are not a surprise. I pointed this to the main maintainer of D-YAML a while back but at this time there was more serious bottlenecks. If you read this "El Pinguino"...

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!

Reddit:
https://www.reddit.com/r/programming/comments/ddmlfy/beating_stdvisit_without_really_trying/

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.

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.

On Saturday, 5 October 2019 at 12:27:06 UTC, Mike Parker 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!
>
> Reddit:
> https://www.reddit.com/r/programming/comments/ddmlfy/beating_stdvisit_without_really_trying/

Correction:

https://www.reddit.com/r/programming/comments/ddi5wb/beating_stdvisit_without_really_trying/

I missed that someone had already shared it.

On Saturday, 5 October 2019 at 04:07:45 UTC, Meta wrote:
> I'm not sure if you're aware, but funnily enough, I also wrote an article[1] on std::variant vs. the D alternative that references Matt Kline's article on std::visit. It seems we're really making getting our money's worth from his article.
>
> I really enjoyed this - I think you're right in that it comes down to the complexity of implementation, and I suspect that C++ forced the developers of std::variant to choose between a usable API (usable, not good) and performance.

I remember seeing your article when it went up on the D blog. It's a great illustration of how things that are complex in C++ are often easy or even trivial in D.

Some of the commenters on reddit brought up boost.variant2 and mpark::variant as alternative C++ implementations that generate the same code as C. So it's clearly *possible* for C++ to get good performance on this. It's just that in C++, you have to work really hard for it, whereas in D, it's so easy you'd have to work harder to get it wrong.

On Saturday, 5 October 2019 at 13:58:52 UTC, Seb wrote:
> On Saturday, 5 October 2019 at 06:40:35 UTC, Arun Chandrasekaran wrote:
>> 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.
>
> 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.

I actually would like to submit SumType to Phobos, albeit as an alternative to Algebraic rather than a replacement for it. Given how dramatic the improvement is, I think it's worth the awkwardness of having two sum type implementations in the standard library.

Currently, the main thing blocking me is bugzilla issue #19458 [1], which (for somewhat complicated reasons [2]) makes it impossible for SumType to support members with @disabled and non-const opEquals overloads.

[1] https://issues.dlang.org/show_bug.cgi?id=19458
[2] https://github.com/pbackus/sumtype/issues/16