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

[Steven Schveighoffer]

On 7/21/21 7:59 PM, Walter Bright wrote:
> On 7/21/2021 2:16 PM, Steven Schveighoffer wrote:
>> No, `mixin something; thenCallFunction(...);` isn't even close to the 
>> same.
> 
> I don't know what it is you're asking for, then.

I'm not asking for anything. What I'm saying is the feature in Swift 
(called "dot syntax") that allows one to use `.enumMember` wherever a 
specific enum is required, is not the same as creating symbol aliases 
for all the enum members in your namespace (or in module namespace). The 
Swift feature is contextual based on the expression *type*, and doesn't 
require any extra machinery around it. This means that you don't have 
weird ambiguities when you have multiple enums as parameters, or names 
that are local that might override the names. e.g.:

```d
enum A
{
    one,
    two,
    three
}

enum B
{
    one,
    two,
    three
}

void foo(A a, B b) {... }

// how to call foo without having to specify `A.one` or `B.one`?
```

In Swift, `.symbol` is specifically for type properties, and fit 
perfectly for enums (and other things, see 
[here](https://www.swiftbysundell.com/tips/using-dot-syntax-for-static-properties-and-initializers/)). 
It does not have the meaning that D has, so it can get away with this.

I don't expect D to implement such a thing, and yes, you can do mixin 
hacks or `with` statements (though there are drawbacks to both). Just 
saying `.member` instead of `FullEnumType.member` whenever a 
`FullEnumType` is required is a nice feature of Swift, and I would like 
to see something like it in D, but I can live without it. BUT if it were 
to be implemented, obviously `.symbol` doesn't work. That's why I 
proposed a shortcut to mean "property of the required type" such as 
`#.symbol`.

-Steve