No we should not support enum types derived from strings

[Timon Gehr]

On 11.05.21 23:36, Andrei Alexandrescu wrote:
> On 5/11/21 2:37 PM, Meta wrote:
>> On Tuesday, 11 May 2021 at 16:44:03 UTC, Andrei Alexandrescu wrote:
>>>> 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.
>>
>> I apologize for injecting myself into this conversation, but with all 
>> due respect, what the hell are you talking about? Everything Deadalnix 
>> is saying makes perfect sense - it's basic type theory, and yet you're 
>> accusing him of moving goalposts and making up definitions, etc. The 
>> problem is that `isSomeString` doesn't respect the LSP and the 
>> template constraints on the relevant stdlib functions for enums are a 
>> hack to work around that. End of story. if `isSomeString` was defined 
>> sensibly, these template constraint hacks would not have to exist.
>>
>> All the bluster about `popFront` on enum strings, etc. is completely 
>> irrelevant, and is a red herring anyway (as was already explained).
>>
>> I'm sorry for being so blunt, but this conversation is painful to read.
> 
> Being blunt is totally cool, but that doesn't make you right.
> ...

Deadalnix is saying that there is a subtyping relationship for rvalues, 
while you are pointing out that there is no subtyping relationship for 
lvalues. I think those are both correct. (Type theory has no notion of 
lvalues or rvalues, so those would indeed have to be interpreted as 
different types.)

I fail to see why the semantics of lvalues should have any bearing on 
format strings even though I understand why most of Phobos might want to 
assume isSomeString talks about lvalues of the type.

> There's no true subtyping or polymorphism with value semantics.
> ...

There's certainly subtyping. The point about "polymorphism" (in type 
theory, polymorphism typically refers to parametric polymorphism, but I 
guess you mean existential types), is a bit more tricky. I guess the 
point is that a language that wants `f(σ) ⊆ ∃τ. f(τ)` to hold without 
any runtime semantics can't support data types whose values do not embed 
runtime type info. However, it can certainly support value types, even 
value types that are stored without indirections.

> the assert was puzzlingly passing. Since everyone here is great at 
> teaching basic type theory, it's an obvious problem - the fix is:
> 
>          assert(typeid(*this) == typeid(Widget));
> ...


That's a C++ quirk. Not much to do with type theory. In fact, C++ may 
not be a great example for illustration, as its type system is unsound.