Enum literals, good? bad? what do you think?

Steven Schveighoffer schveiguy at gmail.com
Fri Jul 23 15:34:34 UTC 2021


On Friday, 23 July 2021 at 01:09:31 UTC, Walter Bright wrote:
> Are you sure that's how Swift works? Inferring the type of the 
> rvalue from the lvalue? Problems come from that, as in:
>
>    z = x + y + .identifier;
>
> For the rvalue, this becomes "top down" type inference, as 
> opposed to the usual "bottom up" type inference. D is 
> exclusively "bottom up", as it is much simpler.

I don't disagree. I think in your example here, it's not 
inferring the requested type from z, but would be from the 
operator overload function. There are two requirements here:

1. The type is inferred before the property is looked up (or at 
least, the set of possible types). Nearly everything in Swift is 
inferred type.
2. The `.identifier` is a self-producing property based on the 
contextual type. That is, it is a property on the 
expected/inferred type, AND it produces an instance of the type.

It helps to remember also that Swift's enums are much more 
configurable than D's enums -- they are actual enumerations, and 
allow you to define properties, operators, etc. They are 
basically a specialized struct (so for instance, you can identify 
whether math is usable on them).

-Steve


More information about the Digitalmars-d mailing list