The contextual inference only takes place in certain contexts. Perhaps we can run with that idea. Let's take case statements:

  enum WordLetterOfTheDay{ a,b,c,d/*...*/ }

  void main(){
    auto letterToday = WordLetterOfTheDay.b;

    import std.stdio;
    switch(letterToday){
        case $a:
            writeln("Apple");
            break;
        case $b:
            writeln("Bicycle");
            break;
        case $c:
            writeln("Caterpillar");
            break;
        case $d:
            writeln("Didgeridoo");
            break;
        /*...*/
    }
  }

and recognize that the SwitchExpression is of type WordLetterOfTheDay. Implicitly enclose the switch body with a `with (WordLetterOfTheDay)` resulting in:

  enum WordLetterOfTheDay{ a,b,c,d/*...*/ }

  void main(){
    auto letterToday = WordLetterOfTheDay.b;

    import std.stdio;
    switch(letterToday){
        case a:
            writeln("Apple");
            break;
        case b:
            writeln("Bicycle");
            break;
        case c:
            writeln("Caterpillar");
            break;
        case d:
            writeln("Didgeridoo");
            break;
        /*...*/
    }
  }

Note the disappearance of the `$`, and use of the leading `.` operator retains its existing meaning.

Applying the same to Initializers and assignments:

  enum A{ a,b,c,d }

  struct S{ A one, two; }

  void main(){
    A    myA1 = b;      // myA1 = A.b
    A    myA2 = b | c;  // myA2 = A.c
    auto myA3 = b;      // error, b is undefined

    S myS;
    myS.one = c; // myB.one = A.c
    myS.two = d; // myB.two = A.d
  }

To Return statements:

  enum A{ a,b,c,d }

  A myFn(){
    return c; //returns A.c
  }

  auto myBrokenFn(){
    return c; // error, c is undefined
  }

Argument lists:

  Only works if there are no overloads.

Array literals:

  enum A{ a,b,c,d }

  // (A)
  A[4] x = [a, b, c, d];
  // (B)
  auto y = [A.a, b, c, d]; // error, b is undefined
  auto z = [A.c, 64, b, b]; // error, b is undefined

Now, suppose instead you write:

  enum A{ a,b,c,d }

  A b = c;
  A[4] x = [a, b, c, d];

Is the `b` A.b or A.c? A.b since the `with` has a narrower scope than the local `b`. If the user wants the local `b`, he will need to rename it.

Advantages of this scheme:

1. doesn't need the special `$` which people don't seem to like, and using `.` conflicts with existing use

2. makes use of the already present `with` semantics

3. seems to have a natural feel to it

I like this design.

On 11/19/22 05:22, Walter Bright wrote:
> Consider this:
> 
>      enum A { a; }
>      enum B { a; }
> 
>      void f(A);
>      void f(B);
> 
>      ...
>      f($a + $a); // mentioned in the DIP as allowed
>      ...
> 
> Since the DIP allows expressions containing such enum inferences, it looks like we are faced with the possibility of having to re-run the semantic pass for enum arguments for every enum overload.

Only if the new feature is actually used, and yes, this is the same as for function literals. I guess the implementation can be optimized further for enum arguments, but I doubt it would make a meaningful difference.

On Saturday, 19 November 2022 at 08:49:31 UTC, Walter Bright wrote:
> The contextual inference only takes place in certain contexts. Perhaps we can run with that idea.

Would this generalize to struct construction like i mentioned here:
https://forum.dlang.org/post/bievvzpabbxddogbmpgu@forum.dlang.org


If you can do an implicit with, you can also do an implicit alias of the with subject. And once you have implicit alias you can  construct a struct which adds to the value significantly.


Actually, I do wish `with` in general had a way to refer back to the subject of it. Maybe we could add something there then it'd magically apply to the implicit with too.

On Saturday, 19 November 2022 at 03:46:55 UTC, Walter Bright wrote:
> True, but you could also do:
>
> with (MySuperLongType):  // <= note colon
> MySuperLongType flag = ValueA | ValueB | ValueC | ValueD | ValueE | ValueF |
>  ValueG;

Something I do before making a post is to run it through the compiler to ensure it actually works like I'm claiming it works. You should do this too.

The colon form is only valid outside functions, not inside them*. Inside a function, you need to use the {} form.

(btw my experience with the colon form outside functions tends to be regret anyway so I very rarely use it anymore anyway.)

* well ok, you can put a nested aggregate inside a function and that's kinda still inside a function. but you know what i mean, i think the grammar calls it a declaration context vs a statement context but i forget the formal words.