draft proposal for Sum Types for D

ryuukk_ ryuukk.dev at gmail.com
Tue Dec 6 20:04:01 UTC 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`][1] and [`ifThrown`][2] 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`][3] and [`xerrors`][4] 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.
>
> [1]: https://phobos.dpldocs.info/std.exception.enforce.1.html
> [2]: https://phobos.dpldocs.info/std.exception.ifThrown.1.html
> [3]: https://pkg.go.dev/errors
> [4]: https://pkg.go.dev/golang.org/x/xerrors

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


More information about the Digitalmars-d mailing list