On 7/22/21 1:19 PM, Walter Bright wrote:

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`?

Swift is known for "giving up" on expression inference, so possibly it could lead there.

But note that Swift (and objective C) have significant parameter names, which means in many cases you must name the parameters when calling. This helps with overloading quite a bit (in fact, in Objective C there was no overloading, as the parameter names were part of the function name).

Which is to say, the situation in Swift is definitely different than the situation in D. Overloads are handled differently, and expectations are significantly different.

I tried out some stuff:

import Foundation

enum Foo {
    case a
    case b
    case c
}

enum Bar {
    case a
    case b
}

func test(_ : Foo) { print("test a"); }
func test(_ : Bar) { print("test b"); }

test(.a) // error, ambiguous
test(Foo.a) // test a
test(Bar.a) // test b
test(.c) // test a

So it seems to work as one might expect. Since .c can only match the first, it's used.

But what is "all" resolutions? A combinatorial explosion of 1 or 2 possibilities isn't bad. Remember, the symbol lookup requires a contextual type. For example:

var x = .identifier // Compiler error, no type, even if only one type in scope has a member `identifier`
var y : SomeEnum = .identifier  // OK
var z : SomeEnum
z = .identifer // OK, we infer the meaning from the type of z

I know D doesn't do this. But it's also not the same as what you are saying.

The identifier comes from the expression target's inferred type. There are still ambiguous cases, where the compiler is going to give up. But the lookup doesn't involve the whole world either.

Before you go on arguing that D doesn't do this, and shouldn't, I know. It's not that I'm trying to convince you that it should, I'm just showing what has been requested and how it differs from the "mixin solution".

The answer is, there is no shortcut, just type out the full enum names. With Swift you do not need to.

-Steve

On Thursday, 22 July 2021 at 14:58:12 UTC, Paul Backus wrote:

There would be a risk that I'd think that it's the same as E e = .y. Not that likely though - I may well know that E has a member y, and I could also reason that ".y" meaning .y would make no sense since one could just write .y directly.

I think you're worried about the case where I don't know that E is an enumerated type. In that case I could mistake E being some sort of string type. On the other hand, I could not fully trust that conclusion anyway, since it could also be some custom struct or union that can be initialized that way.

To some degree yes. But perhaps it's still better than new syntax.

On Thursday, 22 July 2021 at 14:58:12 UTC, Paul Backus wrote:

Oh, I just realized adding the dot solves nothing.

enum E : string { x = ".y", y = ".x" }

E e = ".y"; // *Facepalm*

On Friday, 23 July 2021 at 01:09:31 UTC, Walter Bright wrote:

It could work with bottom-up inference only. It would work the same way as null did before adding the bottom type: .identifier would be a literal of an internal compiler type, let's call it EnumLiteral!"identifier". Values of that internal compiler type would implicitly convert to any enumerated type that defines identifier.

On Friday, 23 July 2021 at 01:09:31 UTC, Walter Bright wrote:

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