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

[H. S. Teoh]

On Fri, Nov 18, 2022 at 07:14:14PM +0000, IGotD- via 
Digitalmars-d wrote:
> On Friday, 18 November 2022 at 17:54:42 UTC, monkyyy wrote:
> > > using $
> > If I define opDollar to return an enum; and you define an 
> > opIndex to
> > take enums; does it all work?
>
> The $myEnum syntax is really hideous compared to the .myEnum. 
> The
> .myEnum syntax feels natural where $myEnum looks like it is 
> some kind
> macro parameter or something. There is a reason that all other 
> example
> languages like Swift use the . syntax.

Yeah, `$` is really hideous and sticks out like a sore thumb in 
typical
D code.  On top of that, it overloads the current usage of $ to
something completely unrelated, which makes it look really messy. 
  Why
can't we just stick with `.`?


> Is it possible to use the . syntax but there is a search 
> hierarchy? If
> there is a global with the same enum name, you must give the 
> full enum
> name. There might creep in serious bugs, however often you will 
> have
> some kind of type mismatch.
[...]

Here's my proposal: use `.` instead of `$`, and if .identifier is
ambiguous in any way at all, prohibit ITE and require spelling 
out the
enum in full. I.e., prohibit it if there's any ambiguity at all 
with a
module name, any global identifier, or it can be a member of 
multiple
enums currently in scope.

After all, your typical use case is an enum member with unique 
member
names, such that it's a pain to have to spell out the enum type 
since
it's already obvious from the name which enum it must belong to. 
If the
enum members don't have obviously unique names (i.e., it's 
ambiguous
with some top-level identifier), then it should be spelled out in 
full,
we should just prohibit eliding the type name.


T

--
Don't drink and derive. Alcohol and algebra don't mix.