enum X { A, B, C}

void foo(X x);

foo(X.A);


vs


enum X { A, B, C}

void foo(with X x);

foo(A);

On Monday, 24 December 2018 at 02:04:26 UTC, Michelle Long wrote:
> enum X { A, B, C}
>
> void foo(X x);
>
> foo(X.A);
>
>
> vs
>
>
> enum X { A, B, C}
>
> void foo(with X x);
>
> foo(A);

You could even support this by default, without requiring `with`. It could break code but it's probably rare that symbols passed to an enum argument collide with members of the enum itself, i.e.

const A = X.B;
Foo(A); // this is probably rare

But we would have to decide which one to give precedence, the enum member scope or the the current scope.

On Mon, 24 Dec 2018 02:04:26 +0000, Michelle Long wrote:
> enum X { A, B, C}
> 
> void foo(X x);
> 
> foo(X.A);
> 
> 
> vs
> 
> 
> enum X { A, B, C}
> 
> void foo(with X x);
> 
> foo(A);

How would that deal with name collisions, static imports, and nested symbols?

Like the standard naming convention is to have camelCase enum value names. So it would be something like:

---
bool caseSensitive = false;
getopt(
  args,
  // std.getopt.config.caseSensitive, std.getopt.config.allowBundling
  caseSensitive, allowBundling,
  "c|case-sensitive", "do a case-sensitive search", &caseSensitive);
---

Yuck.

The call site determines how to refer to symbols currently. It's still a bit complex, dealing with imports, explicit declarations and aliases, type hierarchies, and with statements. This would add even more complexity.

You can reduce the amount of call-site fluff with something like:

---
enum X { a, b, c; }
static foreach (m; __traits(allMembers, X))
{
  mixin("enum " ~ m ~ " = X." ~ m ~ ";");
}
---

On Monday, 24 December 2018 at 02:13:45 UTC, Jonathan Marler wrote:
> On Monday, 24 December 2018 at 02:04:26 UTC, Michelle Long wrote:
>> enum X { A, B, C}
>>
>> void foo(X x);
>>
>> foo(X.A);
>>
>>
>> vs
>>
>>
>> enum X { A, B, C}
>>
>> void foo(with X x);
>>
>> foo(A);
>
> You could even support this by default, without requiring `with`. It could break code but it's probably rare that symbols passed to an enum argument collide with members of the enum itself, i.e.
>
> const A = X.B;
> Foo(A); // this is probably rare

This could still be valid. It is the proper type. With is just for name resolution. Essentially the compiler just prefixes the passed symbol with the enum given but if it knows it is already of the correct type then it can just use that.

> But we would have to decide which one to give precedence, the enum member scope or the the current scope.

I think it only makes sense to use the enum in the function signature since that is the desired one. If it does not match at the call site then an error is thrown.