Crystal: Feature Idea: Auto-prefix `class` and `enum` arguments.

[chris-huxtable]

I am interested in getting a little more involved with the actual compiler and have an idea which I think would be a big improvement to the use of enums. If its thought to be a good idea I would appreciate some guidance on where it might be best to start.

Currently when one submits an enum as an argument it needs to be something like Process::Redirect::Close. It could simply be Close. The method is expecting a Process::Redirect. This produces long lines of repeated information; Process.run(...) for example.

I would like to modify the compiler to assume a prefix on a given enum or class as being that of the expected receiving kind.

Thoughts?

[RX14]

@chris-huxtable I assume this would only work for providing literals in method args, i.e. given

enum A
  Foo
  Bar
end

def foo(enum : A)
end

you can call foo(Foo) but x = Foo; foo(Foo) wouldn't work.

If so, then yes I think this is a simple, easy to understand semantic which should be fairly easy to implement (detecting ambiguity might be hard, i.e. def foo(x : EnumA) and def foo(x : EnumB) overloads where EnumA and EnumB both have a member called Foo). You can probably extend this mechanism to numbers too (if you're expecting a UInt64, you don't have to specify 4_u64).

[ysbaddaden]

it can also conflict with type resolution:

enum Val
  Foo
  Bar
end

class Bar
end

def hello(value : Val)
end

def hello(bar : Bar.class)
end

hello(Bar) # hello(::Bar) or hello(::Val::Bar) ?

I'd still prefer case insensitive symbols (i.e. :redirect) thought, with the same ambiguity/conflict caveats. Because I like symbols and it would avoid visual ambiguities with types.

[bew]

I'd prefer "auto prefix" using symbols for enum only.
Auto prefix for classes looks too ambiguous