Discussion Thread: DIP 1044--Enum Type Inference--Community Review Round 1

[Adam D Ruppe]

Lemme propose a generalization of the concept and an alternative 
syntax.

Consider the following code:

```
class ListBox {
    static struct Option {
          enum Type { Thing }
          Type type;
          string displayText;
    }

    void addOption(Option o) {}
}

ListBox b;

b.addOption(auto(auto.Thing, "foo"));
```


ok so what happens there is the pseudo-namespace auto refers to 
the type of the parameter. is is essentially magic `alias auto = 
typeof(arg);`

first layer i call the constructor, auto(...) is constructing a 
ListBox.Option, which it knows because that's what `addOption` 
takes, so that `auto` is just aliasing that name. The parens 
after it call the ctor exactly the same as if you wrote out 
`ListBox.Option`.

now that constructor takes a ListBox.Option.Type, so the auto 
used in *that* function call refers to *that*, just like your 
enum.

But it isn't limited to just enums.


This would also potentially work in return statements and assign 
expressions.

The type would have to be 100% unambiguous - the function must 
not be overloaded (well except maybe on arity) - so we avoid all 
that complication. Wouldn't work for templates.

Possible thing though:

listbox.addOption(to!auto("some string"))

might be allowed to work, using auto as the alias of the 
unambiguous parameter type could allow this too. I don't find 
this as important of a case to consider though.


BTW I used the word `auto` cuz it is a common thing but it could 
just as well be anything else, it is just a magic temporary alias 
after all.