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