Extended EnumFlags

[ncannasse]

The current standard definition of haxe.EnumFlags is a bit dated, and should be updated to allow the following:

enum E {
  A;
  B;
}

var flags1 : EnumFlags<E> = A;
var flags2 : EnumFlags<E> = A | B;
var flags = (flags1 | flags2) & flags1;
flags |= A;

[ncannasse]

I have supported (1) and (3).
For (2) , it would require compile to support the following : when excepted type is an abstract that has an operation on its own type, we should be able to type the operands expressions with the expected type.

[ncannasse]

Ping @Simn

[Simn]

This seems very related to #2786. In fact, I don't immediately see how the case here is any different.

[Simn]

Ok, so the difference is that in #2786 the operands are typed as the abstract itself, whereas here it's a different type. We already type the operands against the expected type, but that doesn't mean that they become the expected type.

What you're asking for would be the equivalent of processing this as var flags2 : EnumFlags<E> = (A : EnumFlags<E>) | (B : EnumFlags<E>). This doesn't exactly seem unreasonable, but I'm quite worried about unintended side efffects such a change might have.

[Aurel300]

Yeah I would find that behaviour quite strange. How would you deal with ambiguities, e.g. an abstract over Int that also defines an | operator?

[ncannasse]

I'm fine if we don't unify if there's ambiguous choices.
Also just added flags |= A which currently error while flags = flags | A works (requires enum E in separate file)

[ncannasse]

Any update on this @Simn ? :)

[Simn]

I'm quite worried that this will good for the simple EnumFlags example, but is going to cause strange behavior in the real world. But I suppose the best way to find that out is to implement it.