-
Notifications
You must be signed in to change notification settings - Fork 13.3k
if b { x } else { y } requires identical types for x and y #4025
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I agree -- the type of the |
I believe this is the idea of "intersection types". I remember discussing this with another PL researcher at CMU during another project of mine, especially w.r.t. the case of the intersected type being a function (in which the subtyping has to contravary in the argument). Our conclusion was that simply switching between intersection and union isn't actually sound (unless the subtyping relation is a total ordering, which in rust it's not). I haven't seen any literature on the subject but could maybe remember the counterexample if I had to. |
Maybe I'm missing something, but I don't think this requires intersection types, just subtyping? I don't think Rust allows subtyping on function types anyway, though I could be wrong! |
This is a simple matter of subtyping and yes Rust does support subtyping on function types. |
Nominating for milestone 1, well-defined |
Updated example, still fails:
@pcwalton suggests that @nikomatsakis is rewriting the inference pass to use subtyping in even-fewer places than currently used, so this is probably never going to work. Paging @nikomatsakis for confirmation. |
accepted for well-defined milestone |
Couple of things:
|
@graydon for me this example type checks:
|
This appears to have been fixed (both cases in the original code). Including a test in #8485 |
This fails:
while this works (giving the two borrowed pointers the same lifetime):
as does this (not returning the pointers through if {} else {}):
@nikomatsakis suggested the first example should work and that the type checker
should be content if the types of the two arms of the
if{}else{}
expressionhave a common supertype, rather than requiring them to be the same.
The text was updated successfully, but these errors were encountered: