Juraj Kirchheim

I like this. It seems unfortunate that we wind up with two types for the same thing in the stdlib though.

As noted multiple times on slack, I think we're trying to cover two very loosely related problem domains via a single language feature. It was a [pretty bad terrible idea...

The main problem is diamond inheritance via interfaces. ```haxe interface I1 { function method(a:A):Void; } interface I2 { function method(b:B):Void; } class X implements I1 implements I2 {} ``` `X`...

> Are you even allowed to have an two interfaces with functions of the same name? That seems silly. I'm not sure what's unclear here. The following compiles and runs...

> Enum constructors to not have actual functions, they are only typed as such. On all platforms I've checked, they are actual functions. What's more, the type system also treats...

Sorry, I misunderstood. We're in agreement after all: if the default values are actually known, there is no problem. > You can look at haxe/macro/Type.hx and verify for yourself that...

> I really don't think that an implementation which wraps basic values only to then null-check and unwrap them would be acceptable. 1. Is that not what we always do...

Defer would be a superb way to tackle this and also related issues, like the absence of `finally`. In discussions about adding the latter, concerns were raised about how easily...

> While defer is more flexible for existing code it doesn't really drive the eco system towards a single method for cleaning up resources That's an ambitious goal, especially in...

> All wording is going to have cases where it doesn't exactly make sense, be it close, dispose, cleanup, bin_all_the_rubbish, or anything else. If people really feel that strongly about...