No we should not support enum types derived from strings

deadalnix deadalnix at gmail.com
Tue May 11 19:56:05 UTC 2021


On Tuesday, 11 May 2021 at 19:37:55 UTC, Walter Bright wrote:
> On 5/11/2021 12:14 PM, deadalnix wrote:
>> I think your case here is disingenuous, because an int is not 
>> a special kind of float.
> D has no notion of a "special kind of type". It only has a 
> notion of "implicitly convertible".
>
> * An int is implicitly convertible to a float.
>
> * An enum is implicitly convertible to its base type.
>
> The two *must* behave the same way, or the language falls apart 
> with hackish special cases that will never work in a 
> predictable manner.
>
> One could design a language with two kinds of conversions:
>
> 1. is-a-special-case-of
> 2. is-implicitly-convertible-to
>
> but D isn't it.

Except, it is.

D has numerous instance of both already and pretending it doesn't 
really isn't going to lead anywhere useful.

And this very thread is indeed proof that "the language falls 
apart with hackish special cases that will never work in a 
predictable manner."

The fact is that you can't get rid of 1. and support OOP, because 
polymorphism is a key ingredient of OOP. And we even go as far as 
to talk about some of the metaprogramming techniques in D as 
being compile time polymorphism, so so this is clearly a road we 
want to embark on.

The alternative is to go full functional on these things, and, as 
Andrei explain with the tail example, this is an option that 
works as well, but you have to write everything in functional 
style, which makes some code harder to write.

Personally, I'm not interested in D going full functional, 
because I appreciate that different ideas are better expressed in 
different paradigms. But I understand that it means that we must 
have 1.

Now, do we need 2. ? Strictly speaking, we do not. We could just 
say that string float conversion and vice versa must be explicit. 
We can remove alias this, and whatever other feature of the 
language does implicit conversion. I'm actually confident that in 
some cases, that would be a win, but also that we are too far 
gone to realistically be able to remove 2.

So we have both, we need to live with both, and make sensible 
decisions based on that. Pretending that we don't have both only 
leads to the guarantee that we'll make more bad decisions on that 
front in the future.



More information about the Digitalmars-d mailing list