On a side note, It’s worth keeping in mind that TypeScript is meant to be transpiled to JavaScript, so it is has so much more flexibility just because of js loosness, while each haxe’s syntax or feature needs to have bullet proof support for 11 languages together, each with it’s own characteristics and strictness. It might explain why new compiler features are debated so much before being considered.
In addition, haxe was here way before ts was even conceived. 
1 Like
Sure, I have that in mind (I was thinking about using putting such “disclaimer” after posting that). I know it’s not realistic for ask for all that features in Haxe and I’m not doing that. Like I said, I was looking for workarounds and some of the new replies really are helpful.
i.e. @benmerckx’s example - while still explicit is something that’s very useful to have in mind when you’re working with something like that. Thank you for posting that.
If anyone has some other examples of macros or other approaches which can be useful in such cases, I’d be grateful if they can post it here (it doesn’t have to be related to this specific example).
That isn’t really a spectrum though. The only difference is that nominal typing is more explicit, but when it comes to actual unification it is not necessarily more rigid. You seem to have this idea of structural typing being some sort of weak check that mostly leaves you alone, which is a bad way to look at it. Ultimately, both approaches still have to answer if what you’re doing is sound, and I’ve already demonstrated that what you want to do here is not.
Also, TypeScript is not more advanced than Haxe in this regard, it’s actually less advanced given that it allows such assignments. They can get away with it because the JavaScript run-time doesn’t care if you store random nonsense in places it doesn’t belong, but that’s a luxury that we don’t have.
Well, we’ll have to agree to disagree on that. It comes down to arguing semantics and I’m not going to do that.
(but just to make it clear - after the part you quote, I explained which definition of “structural typing” I was using, I can edit the “structural” part to “structural&duck typing” to make it even more clear)
This isn’t a matter of opinion, the simple fact is that you want to generate something that isn’t sound. The only reason you can even contemplate this is because it works on JavaScript and other dynamic targets. If you try to read an int as a string on C++ the best outcome is a segfault. And if a compiler to such a language creates segfaults from perfectly typed code then it is a bad compiler.
If all you want to do is target JavaScript then sure, the option might seem feasible. But in that case I’d honestly just use TypeScript instead of trying to turn Haxe into TypeScript. Differently languages exist for a reason and we’re not trying to appease everyone at the same time.
OK, I’ll try to explain again: I’m OK with some unsoundness and I understand what will happen on static targets if I’m not careful.
I understand the risks and I’m fine with them. Why is that not OK? Even if I do end up shooting myself in the foot, it’s my foot 
By second example do you mean the abstract B(BT) with the static extension?
If so, that is already a edge case for me. I mean, suppose your first question defines the 100% area of a circle, then the abstract problem probably occupies a ~5% sector of it. I almost feel trying to address it here would be out of topic.
If that is not the case, if this use case is not anecdotical for you, it may be worth refining the question and explaining the why in another thread. Then it will be easier to answer more specifically (because from what I see there are 49 messages already here and at least 3 or 4 directions 
).
Yes, you’re right, this thread has become very confusing and impossible to follow.
I wouldn’t call this part with static extension as an edge case, because I need that and I didn’t know that workaround with implicit casts will be incompatible with static extension (btw. I added a feature request on github and if it gets resolved, this part is solved, in a way).
The part which definitely is an “edge case” are my concerns, after some replies, if this language will be a good fit when I need something more flexible. My opinion is still that Simns replies are way too exaggerated in the context of my question, but arguing this any further would be just reiterating the same things over and over, so this part is also “closed”.
I don’t know if there’s a way to mark the thread as closed/solved, but it can be considered as such.