No we should not support enum types derived from strings

[Ola Fosheim Grøstad]

On Monday, 10 May 2021 at 22:58:41 UTC, deadalnix wrote:
> My point is that we already have a language that is a mixed bag 
> of accidentally defined features that don't compose properly 
> with each others. I don't need one more of these, I already 
> have one, and, let's be frank, it has at the very least an 
> order of magnitude more support in the wild, in tools and so on.

Yes, I think everyone can agree with this. A good starting point 
would to implement proper unification of as was discussed some 
months ago. This is critical for composing types in a sensible 
manner (composing templates of templates and binding them to a 
simple name that is exported).

Then one can look and see if some types/features that are 
builtins can be expressed with the same building blocks in a 
unification process (somehow).

When you see what cannot fit into this machinery you get a 
feeling for which features needs to be redesigned.

Something like that.

> Doing the same thing with less manpower is a futile exercise.

Yes.


> Sure, but look at this thread. D is crumbling under the weight, 
> not of the number f feature, but of the fact that a large 
> portion of them simply are unsound.

Yes, but designing something that is sound is best done by having 
a tiny set of (theoretical) mechanisms that all other features 
can be expressed with (even though that might not be visible to 
the end user).

It is very difficult to even discuss soundness with no 
constructive framework to represent ideas with.

> Just look at what's in the C++ standard lib or boost and 
> compare to your average C++ project to see the kind of gap in 
> term of motivation to put up with bullshit exists between 
> standard lib devs and Joe coder. It's not even close.

Yes, even stuff that is well designed in C++ is a lot of work. 
Implementing a new container library with all the iterators is 
quite verbose, tedious and typos will happen...

I think defining protocols and making mechanisms available that 
can extend types with protocols is the way to go (concepts is one 
step in the right direction). How to do it? Not sure, but it 
seems like templating by itself is not enough really.

E.g. if ranges-functionality should be available to everything 
that can be treated like a sequence, then this should be a 
protocol that is present in all the builtin types that are 
sequential. Or somehow bound to them in some global fashion 
(kinda like injected into the type). Nothing should be special 
cased. Ideally.

But there is no clear model for how to do that, I think.

However it is tied to unification. Deduce the protocol if 
possible.