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
I wonder if it makes sense to let the runtime impose types of some functions in Roto, so that the error for it is generated in Roto. So the runtime would say: the function foo needs to have type (u64, IpAddr) -> Prefix or whatever and then the Roto compiler would check that.
There's a couple of advantages to this. First, we can use some type inference for the return types of filter-maps and maybe later some other things. Though I'm not sure we should want that. The other advantage is that we can make nicer error messages for Roto users. A mismatch in types between Rust and Roto is currently presented to the Rust code, not to the Roto code.
The text was updated successfully, but these errors were encountered:
I wonder if it makes sense to let the runtime impose types of some functions in Roto, so that the error for it is generated in Roto. So the runtime would say: the function
foo
needs to have type(u64, IpAddr) -> Prefix
or whatever and then the Roto compiler would check that.There's a couple of advantages to this. First, we can use some type inference for the return types of
filter-maps
and maybe later some other things. Though I'm not sure we should want that. The other advantage is that we can make nicer error messages for Roto users. A mismatch in types between Rust and Roto is currently presented to the Rust code, not to the Roto code.The text was updated successfully, but these errors were encountered: