Closed chris-huxtable closed 6 years ago
@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
).
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.
I'd prefer "auto prefix" using symbols for enum only. Auto prefix for classes looks too ambiguous
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
enum
s. 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 beClose
. The method is expecting aProcess::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
orclass
as being that of the expected receiving kind.Thoughts?