| |
| Posted by ryuukk_ in reply to Paul Backus | PermalinkReply |
|
ryuukk_
Posted in reply to Paul Backus
| 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
|