sumtypes for D

[H. S. Teoh]

On Wed, Nov 30, 2022 at 02:23:20AM +0000, zjh via Digitalmars-d wrote:
> On Wednesday, 30 November 2022 at 01:09:03 UTC, H. S. Teoh wrote:
> > 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.
> 
> How can we improve the `core`?
[...]

By extending the language in such a way that a user type can accomplish
what currently can only be done by a built-in type.

To randomly pick a recent example: const(T)[] can be implicitly cast to
const(T[]), but UserContainer!(const(T)) cannot be implicitly cast to
const(UserContainer!T).  There are various ways of dealing with this:

One way is to ignore it ("the language does not support this"), which is
the current status quo -- the result is that library container types
will always be 2nd class, and they can never fully emulate the behaviour
of built-in arrays.

Another way is to introduce a new built-in type that emulates some or
all of the functionality of UserContainer. It solves this particular
problem (just replace UserContainer with the new built-in type, or some
adaptation of the new built-in type), but the fundamental problem
(Template!(const T) is incompatible with const(Template!T)) remains
unsolved.  Next time, somebody comes along and complains that
AnotherContainer!(const T) is not compatible with
const(AnotherContainer!T), so we're back to square 1 again.

One way to actually solve this problem is to let user types declare the
equivalence between their const forms.  From a discussion a few years
ago I had here on the forum, we could introduce an opImplicitCast
method/template that the compiler looks up whenever user code has an
instance of Container!(const T) but needs an instance of
const(Container!T).  Then there would be some way for this
method/template to cast the container or create a proxy or something, to
produce the needed instance of const(Container!T).  This makes the
language extensible: it doesn't need to invent special rules for
converting between various forms of const in relation to Container, the
definition of Container itself provides the instructions of what to do
to achieve this conversion (or prohibit it, as the case may be).  The
language remains agnostic of how const should interact with user types,
but provides the library author the tools to tell it what to do for each
particular case. (BTW I'm not pushing for this particular solution, just
using it as an illustration of what I'm talking about.)

IOW, empower the user instead of trying to make the language omniscient
about every last imaginable use case.


T

-- 
It is not the employer who pays the wages. Employers only handle the money. It is the customer who pays the wages. -- Henry Ford