No we should not support enum types derived from strings

[Ola Fosheim Grøstad]

On Wednesday, 12 May 2021 at 16:49:12 UTC, deadalnix wrote:
> On Wednesday, 12 May 2021 at 16:38:10 UTC, Ola Fosheim Grøstad 
> wrote:
>> I have to admit I never use the terminology monomorphic and 
>> polymorphic, so my understanding could be wrong. If so, I am 
>> probably not alone in the thread, so for the sake of other 
>> readers, maybe someone can provide a definition for 
>> monomorphic?
>
> It's quite simple.
>
> *a is polymorphic, because it it an object of type A as far as 
> the user of *a is concerned, but it is actually an object of 
> type B (or any other subtype of a).
>
> a itself isn't polymorphic, because it is a pointer to an A no 
> matter what. It is not a pointer to a B that is observed as if 
> it was a pointer to an A. There is nothing more in it to be 
> discovered at run time, it's just a pointer.

I think I understand what you mean, but the terminology used is 
confusing me. A monomorphic function/operator works on only one 
type, but a polymorphic function/operators works on many types.

Seems to me that A* can work on many types, but B* can only work 
on one type (if has no subclasses. So wouldn't that make A* be 
polymorphic in nature, but B* be monomorphic in nature?

I've recently found it better (less baggage) to think in terms of 
protocols than classes. Then A* would be a pointer to something 
that provides the A-protocols. So when an A* pointer points to a 
B instance then we can think of it as if it points to the 
A-protocols that B provides. Maybe then you could claim that it 
is monomorphic as it only binds to A-protocols.

But that is not actually the case, as you have the ability to 
cast A* to B*. So then it would be polymorphic...? I dunno. Seems 
it is a matter of perspective, if "monomorphic" means "of one 
form".