Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Don't automatically virtualize two types in the same hierarchy, unless one is deeper than the other #6024
What this means is that with this PR, the language will now behave like this:
class Foo end class Bar < Foo end class Baz < Foo end var = rand < 0.5 ? Bar.new : Baz.new typeof(var) #=> Bar | Baz
Previously the type would go up to
var = rand < 0.5 ? Bar.new : Foo.new typeof(var) #=> Foo
This makes it possible to have more accurate information about the type of a variable. For example in the compiler's source code we have a
Somehow, compilation times for the compiler don't get much more slower. Memory consumption goes a bit higher (most probably because now there are some union types that previously would go up to
PLEASE, if you can, checkout this branch, compiler the compiler, and try it in your projects. Many things can happen:
Once and if we can go ahead with this change, I'd like to revisit #4837, as it can be another great addition for more type safey and accuracy in the language, avoiding useless
Yeah, I was cleaning up branches and I accidentally deleted my old attempt at it. Then I said "maybe I can try it once more and see how bad it was". I probably did something different this time, because it didn't become that much worse.
I think at least in the parser it would be worth it to add explicit casts to ASTNode in a few places to avoid the many different union types. The main issue here is that this is a guess game, unless we somehow provide a tool to list methods or places where big (or not so big) union types are formed. I don't feel comfortable generating redundant code under the hood, but that's how the language worked all the time (in some code spots, usually when you have a big hierarchy like ASTNode has, so I believe it's more relevant in parsers and compilers), and so far it didn't seem to bother anyone other than me, so ai guess it's fine.
Apr 30, 2018
Hey, since this happened, my project (https://gitlab.com/WitchKnight/ParadoxPyramid) can't compile anymore...