DIPX: Enum Literals / Implicit Selector Expression

[ShadoLight]

On Thursday, 30 June 2022 at 20:32:49 UTC, ryuukk_ wrote:
> On Thursday, 30 June 2022 at 17:15:46 UTC, ShadoLight wrote:
>> On Thursday, 30 June 2022 at 11:32:42 UTC, ryuukk_ wrote:
>>
>>
>> ```
>>     with(MySuperLongName) set_my_flag( MyFlagA |  MyFlagB | 
>> MyFlagC | MyFlagD | MyFlagE | MyFlagF);
>> ```
>> More clear at the cost of a few more characters to type. Quite 
>> acceptable compromise in my view.
>
> Now it is harder to see the function,
>
At the cost of a CR you get:

```
     with(MySuperLongName)
     set_my_flag( MyFlagA |  MyFlagB | MyFlagC | MyFlagD | MyFlagE 
| MyFlagF);
```

For me it is pretty much equal to visually parsing a UDA on a 
function. But that is just me.

>
> It is not nice when you just want to call a function with your 
> enum

Maybe, but it is less ambiguous. In your scheme:

```
     int MyFlagA = 3;

     void main()
     {
         enum MySuperLongName {MyFlagA, MyFlagB, MyFlagC, MyFlagD, 
MyFlagE, MyFlagF }

         //Clearly using the enum ...
         set_my_flag( .MyFlagA |  .MyFlagB | .MyFlagC | .MyFlagD | 
.MyFlagE | .MyFlagF);

         //Using the enum or the global ...?
         set_my_flag( .MyFlagA );

     }

     void set_my_flag(int x){}
```

> You don't do:
>
>     with(int) set_my_int(5 + 6 + 7 + 8 + 9 +10);
>
> It kills the intent to make things simpler and logical, 
> functions expect Enum, we give its value
>
> Function expect int? we give a value

That is only true because of implicit conversion. If set_my_int 
function was declared as ```void set_my_int(short x)```, then the 
```set_my_int(5 + 6 + 7 + 8 + 9 +10);``` statement will not 
compile (even though the value passed to x will fit in a short) 
and you will need to cast to short to shut the compiler up.

I would agree with you if we didn't have something like 
```with(enumName)```, and needed to add the enumName on every 
member. But we do have the ```with(enumName)```, which is an 
acceptable solution to me.

Also, the fact that the ```.enumMember``` syntax is conflated 
with 'parent scope' and can in addition be ambiguous, makes me 
suspect you will need to find a better syntax to get popular 
support for this idea.