December 05, 2022

On Saturday, 3 December 2022 at 16:17:19 UTC, John Colvin wrote:

>

On Tuesday, 29 November 2022 at 06:26:20 UTC, Walter Bright wrote:

>

Go ahead, Make My Day! Destroy!

https://github.com/WalterBright/DIPs/blob/sumtypes/DIPs/1NNN-(wgb).md

I don’t want to be discouraging of good work, but D is not lacking in great features, it is lacking in its implementation of the basics.

Rationale explains it as a safe union. Whether safe union is really needed is a different question, but at least it's consistent with the safety effort.

December 05, 2022

On Monday, 5 December 2022 at 14:50:47 UTC, Paul Backus wrote:

>

IMO if you want this kind of extensibility, a sum type is the wrong tool for the job. This is exactly the use case that classes are designed for: extending existing code to operate on new types, without modifying the code itself.

Sum types, by contrast, excel when the set of types is fixed, but you would like to be able to define new operations on that set of types without changing existing code.

That would be the case, but D has things like BetterC which doesn't support classes (okay, it supports C++ classes, but still).

There are other cases where one might need to extend such sum types, say, you want to extend error types, etc.

December 05, 2022

On Monday, 5 December 2022 at 17:31:11 UTC, Jacob Shtokolov wrote:

>

On Monday, 5 December 2022 at 14:50:47 UTC, Paul Backus wrote:

>

IMO if you want this kind of extensibility, a sum type is the wrong tool for the job. This is exactly the use case that classes are designed for: extending existing code to operate on new types, without modifying the code itself.

Sum types, by contrast, excel when the set of types is fixed, but you would like to be able to define new operations on that set of types without changing existing code.

That would be the case, but D has things like BetterC which doesn't support classes (okay, it supports C++ classes, but still).

If the problem is that BetterC has poor support for classes, then the solution should be to improve BetterC's support for classes (e.g., by making D classes less dependent on TypeInfo).

>

There are other cases where one might need to extend such sum types, say, you want to extend error types, etc.

The Rust community has come up with a variety of techniques to handle cases like this using library code. I am confident that D, with its powerful metaprogramming and reflection, is capable of handling them just as well, if not better.

December 06, 2022

On Monday, 5 December 2022 at 18:41:39 UTC, Paul Backus wrote:

>

On Monday, 5 December 2022 at 17:31:11 UTC, Jacob Shtokolov wrote:

>

On Monday, 5 December 2022 at 14:50:47 UTC, Paul Backus wrote:

>

IMO if you want this kind of extensibility, a sum type is the wrong tool for the job. This is exactly the use case that classes are designed for: extending existing code to operate on new types, without modifying the code itself.

Sum types, by contrast, excel when the set of types is fixed, but you would like to be able to define new operations on that set of types without changing existing code.

That would be the case, but D has things like BetterC which doesn't support classes (okay, it supports C++ classes, but still).

If the problem is that BetterC has poor support for classes, then the solution should be to improve BetterC's support for classes (e.g., by making D classes less dependent on TypeInfo).

>

There are other cases where one might need to extend such sum types, say, you want to extend error types, etc.

The Rust community has come up with a variety of techniques to handle cases like this using library code. I am confident that D, with its powerful metaprogramming and reflection, is capable of handling them just as well, if not better.

Zig and Go does it better, they don't need any "library" "reflection" "metaprogramming", i would never use a language that needs a library to work with errors, it's tasteless

December 06, 2022

On Tuesday, 6 December 2022 at 14:44:03 UTC, ryuukk_ wrote:

>

On Monday, 5 December 2022 at 18:41:39 UTC, Paul Backus wrote:

>

On Monday, 5 December 2022 at 17:31:11 UTC, Jacob Shtokolov wrote:

>

There are other cases where one might need to extend such sum types, say, you want to extend error types, etc.

The Rust community has come up with a variety of techniques to handle cases like this using library code. I am confident that D, with its powerful metaprogramming and reflection, is capable of handling them just as well, if not better.

Zig and Go does it better, they don't need any "library" "reflection" "metaprogramming", i would never use a language that needs a library to work with errors, it's tasteless

You don't need a library, but that doesn't mean it can't be useful to have one. For example: in D, you can write all of your throw and catch and scope (exit) statements by hand if you want, but many users prefer to use library functions like enforce and ifThrown to simplify their code.

In fact, it's kind of funny that you bring up Go as an example here, because many Go programmers use libraries like errors and xerrors that build on top of the built-in error handling features to make them more convenient and ergonomic. Of course, you don't need them, just like you don't need enforce in D, but they are still nice to have.

December 06, 2022

On Tuesday, 6 December 2022 at 14:44:03 UTC, ryuukk_ wrote:

>

Zig and Go does it better, they don't need any "library" "reflection" "metaprogramming", i would never use a language that needs a library to work with errors, it's tasteless

Let's get one thing clear in this thread, if nothing else: the Go error handling model is not one that anyone should be copying. It's verbose, unsafe, dysfunctional, and nobody should be pointing to it as an example of good design.

December 06, 2022

On Tuesday, 6 December 2022 at 17:46:47 UTC, Paul Backus wrote:

>

On Tuesday, 6 December 2022 at 14:44:03 UTC, ryuukk_ wrote:

>

On Monday, 5 December 2022 at 18:41:39 UTC, Paul Backus wrote:

>

On Monday, 5 December 2022 at 17:31:11 UTC, Jacob Shtokolov wrote:

>

There are other cases where one might need to extend such sum types, say, you want to extend error types, etc.

The Rust community has come up with a variety of techniques to handle cases like this using library code. I am confident that D, with its powerful metaprogramming and reflection, is capable of handling them just as well, if not better.

Zig and Go does it better, they don't need any "library" "reflection" "metaprogramming", i would never use a language that needs a library to work with errors, it's tasteless

You don't need a library, but that doesn't mean it can't be useful to have one. For example: in D, you can write all of your throw and catch and scope (exit) statements by hand if you want, but many users prefer to use library functions like enforce and ifThrown to simplify their code.

In fact, it's kind of funny that you bring up Go as an example here, because many Go programmers use libraries like errors and xerrors that build on top of the built-in error handling features to make them more convenient and ergonomic. Of course, you don't need them, just like you don't need enforce in D, but they are still nice to have.

Oh ok "to enhance" them, the part i missed

December 06, 2022

On Tuesday, 6 December 2022 at 18:07:21 UTC, Meta wrote:

>

On Tuesday, 6 December 2022 at 14:44:03 UTC, ryuukk_ wrote:

>

Zig and Go does it better, they don't need any "library" "reflection" "metaprogramming", i would never use a language that needs a library to work with errors, it's tasteless

Let's get one thing clear in this thread, if nothing else: the Go error handling model is not one that anyone should be copying. It's verbose, unsafe, dysfunctional, and nobody should be pointing to it as an example of good design.

I agree with you, i was referring to having error as built-in as opposed to having them as library, but i missed the "to enhance them" part

3 4 5 6 7 8 9 10 11 12 13
Next ›   Last »