Skip to content
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

Tweak closure return type annotation to eliminate future limitations for type grammar #968

Merged
merged 1 commit into from
Mar 16, 2015
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions text/0000-closure-return-type-syntax.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
- Feature Name: N/A
- Start Date: (fill me in with today's date, YYYY-MM-DD)
- RFC PR: (leave this empty)
- Rust Issue: (leave this empty)

# Summary

Restrict closure return type syntax for future compatibility.

# Motivation

Today's closure return type syntax juxtaposes a type and an
expression. This is dangerous: if we choose to extend the type grammar
to be more acceptable, we can easily break existing code.

# Detailed design

The current closure syntax for annotating the return type is `|Args|
-> Type Expr`, where `Type` is the return type and `Expr` is the body
of the closure. This syntax is future hostile and relies on being able
to determine the end point of a type. If we extend the syntax for
types, we could cause parse errors in existing code.

An example from history is that we extended the type grammar to
include things like `Fn(..)`. This would have caused the following,
previous, legal -- closure not to parse: `|| -> Foo (Foo)`. As a
simple fix, this RFC proposes that if a return type annotation is
supplied, the body must be enclosed in braces: `|| -> Foo { (Foo) }`.
Types are already juxtaposed with open braces in `fn` items, so this
should not be an additional danger for future evolution.

# Drawbacks

This design is minimally invasive but perhaps unfortunate in that it's
not obvious that braces would be required. But then, return type
annotations are very rarely used.

# Alternatives

I am not aware of any alternate designs. One possibility would be to
remove return type anotations altogether, perhaps relying on type
ascription or other annotations to force the inferencer to figure
things out, but they are useful in rare scenarios. In particular type
ascription would not be able to handle a higher-ranked signature like
`for<'a> &'a X -> &'a Y` without improving the type checker
implementation in other ways (in particular, we don't infer
generalization over lifetimes at present, unless we can figure it out
from the expected type or explicit annotations).

# Unresolved questions

None.