Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Fix restriction of valid type vs free vars #7536
referenced this pull request
Mar 10, 2019
Thanks for the review
Just a note, since I currently can't check from the restriction method if the type is really a free var, this happens:
# No free vars here, and Foo doesn't exist def bar(a : Foo.class) puts "Hello from Foo" end def bar(a : Int32.class) puts "Hello from Int32" end # Before: bar(Int32) # Error: undefined constant Foo # After bar(Int32) # "Hello from Int32"
@bew Yes, I'm not sure. I think it's bad that if you don't invoke the method you don't get the "undefined constant Foo" either way. We should probably have a pass to compute those types before analyzing calls, and then in the restriction you would know whether a type is a free var or not. For now maybe this is fine.
I think the new behavior is fine.
I'm not sure how you could fix that, since you could have:
def bar(a : Foo.class) puts "Hello from Foo" end def bar(a : Int32.class) # restriction happens here when this method is processed puts "Hello from Int32" end record Foo # define Foo here! bar(Foo) # => "Hello from Foo"
But maybe if there's first a pass to find all types, then a pass to process al methods that could do it, but there will be other problems I think, like macros that creates types / create methods / use
@bew Macros run on the very first pass. This second pass would check the types of all method arguments to see if they exist (they must either be in scope or declared as free variables). I'm almost sure it's something doable. But it's tricky because methods are also added on the first pass (though they are not type-checked there, and this is why it's tricky to compute which one is stricter than the other). We should probably also have some context of
But let's merge this for now.
Mar 13, 2019
5 checks passed
Yes that's what I was thinking, for example the