Inline/anonymous enum declaration

[dogles]

It would be handy to support anonymous enums in Haxe, similar to how anonymous types are supported.

Proposed syntax:

function (a:Int, b:Int, type : enum {Gain; Standard;}) {
   switch (type) {
    case Gain: ...
    case Standard: ...
  }
}

This was what got me thinking about it:
http://mortoray.com/2015/06/15/get-rid-of-those-boolean-function-parameters/

[nadako]

This is an interestring idea. I also often use enums for function args only, so it would be handy to be able to define those right in the signature.

[waneck]

Funny that Mortoray used to be a Haxe user back in the days ;)

[back2dos]

There's a macro for that: https://gist.github.com/back2dos/2785f42c5a52a7f2369a#file-usage-hx :P

It's just a proof of concept, but if there is really value to this, it should get you started. Personally I find error messages with types that have no names really unintelligible. Introducing a type with a well chosen name is sometimes hard, but it's well worth the effort, as it makes code much more readable.

[nadako]

Hmm, that macro is very cool, I didn't even think about that. BTW, I think we can loose the array decl and use Rest argument instead.

[back2dos]

Good point. Slightly related question: will that become @:rest T at some point?

[dogles]

@back2dos very cool :)

[nadako]

Not very beautiful syntatically tho... (array decl, var keyword)

[ncannasse]

Nice macro indeed !
It could be improved by sorting the constructors + caching the enum signature so two same declarations in different places lead to the same enum :)

[Simn]

@nadako: I'm not sure you could get rid of the array declaration, it's the only reliable way to enter expression-mode as far as I know.

[nadako]

Yeah I understand that. It's just one of the reason that macros is not the ultimate answer for everything: here they bring redundant syntax that makes harder for a reader to understand that it's an enum declaration. IMO.

[nadako]

will that become @:rest T at some point?

I'm not sure about that. With @:const T it makes sense to give a name to the type parameter, but with Rest it's redundant, so maybe it's better to keep it as is.

Ideally we would have some special syntax for that (as well as haxe.Rest argument type).

[Simn]

class AnonEnum<...>

\o/

[nadako]

I think it would be better to have a name there also, e.g. class AnonEnum<...Constructors>.

Also actually we could enable that for enums/abstracts for clarity (i.e. enum AnonEnum<...Ctors> {}), see #3640

[nadako]

Lol, ignore my @:rest T redundancy comment, the name could still be useful (class AnonEnum<@:rest Ctors>)

[back2dos]

@nadako Yep, it's a bit quirky. It was either EVar or ECheckType, which is even more ascii-arty ... but I think it's good enough for enum declarations that should fit into a function signature. It's really just a sketch to move the focus of this issue from feasibility to usefulness.

@ncannasse Correct. Although for that to actually work, all ComplexTypes need to be resolved to Types in the current context and then the signature has to be calculated based on those (because otherwise you may get collisions based on imports) and the generated enum needs to be built based on the Types (because it has it's own import context). And for that to fully work one also needs proper handling of type parameter handling, and so on, and so forth. While I'm really into expressive syntax, I don't see enough value in this to actually make a solid implementation. Names are powerful!

@Simn: You made my day!

[Simn]

I'm not sure what the status is here. The idea seems interesting for small cases, but is it practical beyond that?

[back2dos]

I don't think so. All this saves you is one identifier, that would name the enum (and typing private if you feel it should not be visible elsewhere).

There's a lot of approaches that I think would solve this as a side effect. Be it first class type unions, the type system being aware of string constants (as in TypeScript) or maybe symbols (as in Ruby or ES6).

I think #4281 is somewhat relevant to this. It links to this rather intriguing proposal that made it into TypeScript: microsoft/TypeScript#1003

[Simn]

Alright then, let's close this for now.