sumtypes for D

[Paulo Pinto]

On Wednesday, 30 November 2022 at 01:09:03 UTC, H. S. Teoh wrote:
> On Wed, Nov 30, 2022 at 12:42:38AM +0000, deadalnix via 
> Digitalmars-d wrote:
>> On Wednesday, 30 November 2022 at 00:10:47 UTC, H. S. Teoh 
>> wrote:
> [...]
>> > +1, I think this is a better approach.  If a library type 
>> > can't do what a built-in type does, then extend the language 
>> > until it can. As Andrei said in TDPL: "experience has shown 
>> > time and again that offering many magic types that are 
>> > unattainable to user code is a frustrating proposition and a 
>> > sign of poor language design" [TDPL, 2010 ed, p.239].
> [...]
>> Damn, this Andrei guy, he knew one thing or two...
>
> And to elaborate a little, for those people who groan at "yet 
> another library type": a common objection is that a library 
> type has poorer error messages.  Well, it's just the same thing 
> in different clothes: if a library type can't have good error 
> messages, why is that?  Because the language cannot express 
> certain things, or can't do it well, so the library author's 
> hands are tied.  Giving up and pushing the type into the 
> language is merely avoiding the problem (now the compiler 
> writer has to solve the same problems, only in the compiler -- 
> the amount of effort required is equivalent).  What actually 
> addresses the problem is: fix the language so that the library 
> author *can* provide good error messages.
>
> Because this isn't just about adding sumtype or whatever other 
> magic type, this is about making it possible for *any* user 
> type to provide the same level of functionality as built-in 
> types.  It's about empowering the library writer so that he can 
> replicate the power of a built-in type, integrated so well into 
> the language that it feels like native type.  This includes 
> containers that behave like built-in arrays, ARC'd types that 
> behave like pointers, etc..  Solve this at the core, and it 
> will enable progress on many other fronts.  Fail at this, and 
> you're doomed to putting out individual fires one by one, ala 
> whack-a-mole.  Today it's sumtypes, tomorrow it's ARC types, 
> the next day it's head-immutable, it will never end.
>
>
> T

We already have C++ for that, beware of having wishes coming true.