October 28, 2022

On Friday, 28 October 2022 at 12:37:22 UTC, Paul Backus wrote:

>

On Friday, 28 October 2022 at 12:34:42 UTC, ryuukk_ wrote:

>

std.sumtype is buggy, it's slow and it is a template

C/C++ also had them with MACROs, why do you think they decided to now have them has built in feature?

If you've found any bugs in std.sumtype, please report them on issues.dlang.org or https://github.com/pbackus/sumtype/issues!

The only fix is to make it a builtin language feature, the burden should not be on the users

It is similar with Nullable

Try to compile this: https://github.com/d-language-server/dls

And try to decipher the error messages full of template mess

October 28, 2022

On Friday, 28 October 2022 at 14:02:37 UTC, ryuukk_ wrote:

>

The only fix is to make it a builtin language feature, the burden should not be on the users

It is similar with Nullable

We do have a builtin nullable. Given a type T, the builtin nullable variant of it is T*.

October 28, 2022

On Friday, 28 October 2022 at 14:15:28 UTC, Dukc wrote:

>

On Friday, 28 October 2022 at 14:02:37 UTC, ryuukk_ wrote:

>

The only fix is to make it a builtin language feature, the burden should not be on the users

It is similar with Nullable

We do have a builtin nullable. Given a type T, the builtin nullable variant of it is T*.

We should have learnt from Kotlin, C#, Zig, Rust and countless more languages, and make it ? and call it optional, but nope, it had to be a template, and the syntax changed at will by its author without consertation and consideration for its users!

October 28, 2022

On Friday, 28 October 2022 at 14:19:20 UTC, ryuukk_ wrote:

>

We should have learnt from Kotlin, C#, Zig, Rust and countless more languages, and make it ? and call it optional, but nope, it had to be a template, and the syntax changed at will by its author without consertation and consideration for its users!

Rust do not have a "type?" in order to make it an optional what I know about. You have to use Optional. The Rust syntax is very explicit and often not that nice to read. Also Rust does not have optional chaining (ex. let i = var1?.var2?.var3) like C# and Swift which is really nice. In Rust you must use "and_then" or nested if let statements which is super ugly.

October 28, 2022

On Friday, 28 October 2022 at 14:15:28 UTC, Dukc wrote:

>

On Friday, 28 October 2022 at 14:02:37 UTC, ryuukk_ wrote:

>

The only fix is to make it a builtin language feature, the burden should not be on the users

It is similar with Nullable

We do have a builtin nullable. Given a type T, the builtin nullable variant of it is T*.

I really wonder whether we'd have problems with nullables if scope T* a = new T() always allocated on the stack, with some way to denote to allocate on the heap if one wants to do that

October 28, 2022

On Friday, 28 October 2022 at 12:36:48 UTC, ryuukk_ wrote:

>

On Friday, 28 October 2022 at 12:34:42 UTC, ryuukk_ wrote:

>

On Friday, 28 October 2022 at 09:35:06 UTC, Sergey wrote:

>

On Thursday, 27 October 2022 at 15:14:30 UTC, ryuukk_ wrote:

>

PHP also got builtin sumtype and pattern matching

https://laravel-news.com/modern-php-features-explained

https://news.ycombinator.com/item?id=33357318

D lagging behind most languages now :/

PHP is hardly a competitor to D.

> > >

D also has them: https://dlang.org/phobos/std_sumtype.html#match

std.sumtype is buggy, it's slow and it is a template

C/C++ also had them with MACROs, why do you think they decided to now have them has built in feature?

Has C or C++ actually added sum types to their standards?

>

Only with D the solution is a template, then your program takes 30 seconds to compile and people wonder why it is slow, don't put the burden on the users for something this essential, it doesn't look good

D templates are fast, unlike in C++. Maybe you're using other features like CTFE slowing things down. Or maybe the front end isn't using GC and you're short on memory. Either way doesn't seem like a fundamental criticism of std.sumtype, though they may exist.

October 28, 2022

On Friday, 28 October 2022 at 14:42:14 UTC, IGotD- wrote:

>

On Friday, 28 October 2022 at 14:19:20 UTC, ryuukk_ wrote:

>

We should have learnt from Kotlin, C#, Zig, Rust and countless more languages, and make it ? and call it optional, but nope, it had to be a template, and the syntax changed at will by its author without consertation and consideration for its users!

Rust do not have a "type?" in order to make it an optional what I know about. You have to use Optional. The Rust syntax is very explicit and often not that nice to read. Also Rust does not have optional chaining (ex. let i = var1?.var2?.var3) like C# and Swift which is really nice. In Rust you must use "and_then" or nested if let statements which is super ugly.

I should have developed further, but you did it for me so thanks

October 28, 2022

On Friday, 28 October 2022 at 14:43:54 UTC, Nick Treleaven wrote:

>

Has C or C++ actually added sum types to their standards?

It was proposed and feedback was favorable, it's only just a matter of when now

October 28, 2022

On Friday, 28 October 2022 at 14:47:27 UTC, ryuukk_ wrote:

>

On Friday, 28 October 2022 at 14:43:54 UTC, Nick Treleaven wrote:

>

Has C or C++ actually added sum types to their standards?

It was proposed and feedback was favorable, it's only just a matter of when now

Do you have a link? I saw the circle compiler extension and feedback wasn't all favourable. Standardising something is long and arduous.

October 28, 2022

On Friday, 28 October 2022 at 14:49:28 UTC, Nick Treleaven wrote:

>

On Friday, 28 October 2022 at 14:47:27 UTC, ryuukk_ wrote:

>

On Friday, 28 October 2022 at 14:43:54 UTC, Nick Treleaven wrote:

>

Has C or C++ actually added sum types to their standards?

It was proposed and feedback was favorable, it's only just a matter of when now

Do you have a link? I saw the circle compiler extension and feedback wasn't all favourable. Standardising something is long and arduous.

Here is the latest revision i could find

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1371r3.pdf

And Bjarne Stroustrup thoughts

https://www.open-std.org/JTC1/SC22/WG21/docs/papers/2021/p2411r0.pdf

>

Final words

>

I am still of the opinion that after a general model of concurrency, a module version of the standard
library, and library support for coroutines, pattern matching is the most promising addition to the
language for the (relatively) near future [P2000].