No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/11/21 12:39 PM, Andrei Alexandrescu wrote:
> On 5/11/21 12:13 PM, deadalnix wrote:
>> On Tuesday, 11 May 2021 at 15:19:05 UTC, Andrei Alexandrescu wrote:
>>> On 5/11/21 10:34 AM, deadalnix wrote:
>>>> On Tuesday, 11 May 2021 at 13:56:50 UTC, Andrei Alexandrescu wrote:
>>>>> Then enum strings are not ranges, correct?
>>>>
>>>> They are not. But they are strings. Which imply that string aren't 
>>>> ranges, which is right, `ref strings` are ranges, not strings.
>>>
>>> `ref string` is not a type.
>>
>> This is just denial.
> 
> It's simple fact.
> 
>> There are many exemple of conversions that differs with string and ref 
>> strings which do not involve enums. For instance, immutable(string) -> 
>> string is a valid conversion, but immutable(string) -> ref string isn't.
>>
>> Call it something else than a type if you want, nevertheless, 
>> conversions rules are simply different, even if you abstract the 
>> notion of rvalue/lvalue from the whole thing, so it is clearly more 
>> than just a regular storage class.
>>
>> When you say ref, you say "I do not want a subtype". Saying B isn't a 
>> subtype of A because I can't pass a B to what expects a ref A is just 
>> fallacious.
> 
> Again with moving the goalposts.

To clarify: you can't make up your own definitions as you go so as to 
support the point you're making at the moment. You can't go "oh, call it 
something else than a type, my point stays". No. Your point doesn't stay.

By the same token you can't make up your own definition of what 
subtyping is and isn't. Value types and reference types are well-trodden 
ground. You can't just claim new terminology and then prove your own 
point by using it.