No we should not support enum types derived from strings

[deadalnix]

On Monday, 10 May 2021 at 22:37:51 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 10 May 2021 at 21:44:02 UTC, deadalnix wrote:
>> The bad news is, there is already a language like this. It's 
>> called C++, and it's actually quite successful. With all due 
>> respect to you and Walter, you guys are legends, but I think 
>> there is also a bit of learned helplessness coming from both 
>> of you due to a lifetime of exposure to the soul corroding 
>> effects of C++.
>
> Not sure how this applies to C++, what subtyping issues are you 
> having with C++?
>

Function type don't have the right covariance/contravariance, you 
can slice subtypes, and there are more, but this is not my point.

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.

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

>> This attitudes pervades everything, and most language 
>> constructs suffer of some form of it in one way or another, 
>> causing a cascade of bad side effects, starting with this 
>> whole thread. A few examples en vrac for instance: DIP1000, 
>> delegate context qualifiers, functions vs first class 
>> functions, etc...
>
> That's a direct result of the process. Features have always 
> been added as an experiment rather than being completed on 
> paper, even the ones with a DIP. At this point, this pretty 
> much defines what D is... Just look at the addition of a C 
> compiler that is being advanced right now. It is being added 
> because there might be some benefits from it the future, 
> perhaps. Of course, you also have the side effect that the AST 
> becomes more resistant to change... and refactoring costs 
> doubles...
>
> So that is why D has these issues. People wanted something, and 
> it was added in an experimental way, not in an analytical way. 
> That is the way of D. Experiment in features.
>

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.

At this point, the decision made is to push the madness on the 
user. Fair enough, but if the standard lib devs are not willing 
to put up with it, why in hell would you expect anyone else to? 
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.

This stuff ain't working properly so let's just given getting to 
work at all is not how you iterate toward a great useful product.