You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
from Standard.Base import all
f (x : Integer) = x+x
type My_Type
Value
g self (y : Integer) = y+y+y
main =
o = My_Type.Value
IO.println (o.g 1)
IO.println (o.g "A")
h (z : Integer) = z+z+z+z
IO.println (h 1)
IO.println (h "A")
IO.println (f 1)
IO.println (f "A")
Expected behaviour:
It should fail with type error at o.g "A" and (if the first erroneous line is commented out) on h "A".
Something like:
3
Execution finished with an error: Type error: expected `y` to be Integer, but got Text.
at <enso> My_Type.g(test.enso:9:?-??)
at <enso> test.main<arg-1>(test.enso:14:??-??)
at <enso> test.main(test.enso:14:?-??)
Actual behaviour
3
AAA
4
AAAA
2
Execution finished with an error: Type error: expected `x` to be Integer, but got Text.
at <enso> test.f(test.enso:3:1-22)
at <enso> test.main<arg-1>(test.enso:21:17-21)
at <enso> test.main(test.enso:21:5-22)
The typechecks in o.g and h are not performed.
The local definition (h) is probably of a lower priority, as we don't need these as much - although ideally we want it to behave in a consistent way with other kinds of definitions - otherwise making the language behave inconsistently will make it harder to learn (as the user will need to know all the exceptions).
But the o.g case is very important - most of our library APIs are methods on types, we have very very few standalone top-level methods. So to be able to actually benefit from the ascribed typechecks, we need to ensure that they work correctly in such scenarios.
The text was updated successfully, but these errors were encountered:
JaroslavTulach
changed the title
Runtime check of ascribed types seems to only apply to top-level definitions
Runtime check of ascribed types do not work for methods
May 30, 2023
JaroslavTulach
changed the title
Runtime check of ascribed types do not work for methods
Runtime check of ascribed types does not work for methods
May 30, 2023
JaroslavTulach
changed the title
Runtime check of ascribed types does not work for methods
Runtime check of ascribed types does not work for instance methods
May 30, 2023
3
Execution finished with an error: Type error: expected `y` to be Integer, but got Text.
at <enso> My_Type.g(m.enso:9:5-32)
at <enso> m.main<arg-1>(m.enso:14:17-23)
at <enso> m.main(m.enso:14:5-24)
however that's not checking the behavior of h, right? But:
from Standard.Base import all
main =
h (z :Integer) = z+z+z+z
IO.println (h 1)
IO.println (h "A")
is also working fine:
4
Execution finished with an error: Type error: expected `z` to be Integer, but got Text.
at <enso> h(m.enso:4:5-29)
at <enso> m.main<arg-1>(m.enso:6:17-21)
at <enso> m.main(m.enso:6:5-22)
JaroslavTulach
changed the title
Runtime check of ascribed types does not work for instance methods
Runtime check of ascribed types works only for static methods
May 30, 2023
Try running:
Expected behaviour:
It should fail with type error at
o.g "A"
and (if the first erroneous line is commented out) onh "A"
.Something like:
Actual behaviour
The typechecks in
o.g
andh
are not performed.The local definition (
h
) is probably of a lower priority, as we don't need these as much - although ideally we want it to behave in a consistent way with other kinds of definitions - otherwise making the language behave inconsistently will make it harder to learn (as the user will need to know all the exceptions).But the
o.g
case is very important - most of our library APIs are methods on types, we have very very few standalone top-level methods. So to be able to actually benefit from the ascribed typechecks, we need to ensure that they work correctly in such scenarios.The text was updated successfully, but these errors were encountered: