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.

Sign up for GitHub

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

Jump to bottom

RFC: "as" should be "as PATH" or "as (TYPE)" #96

Closed
wants to merge 1 commit into from
Closed

RFC: "as" should be "as PATH" or "as (TYPE)" #96

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
27 changes: 27 additions & 0 deletions active/0000-as-paths.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
- Start Date: 2014-05-28
- RFC PR #: (leave this empty)
- Rust Issue #: (leave this empty)

# Summary

The `as` production in the grammar should be `as PATH` or `as (TYPE)` (with the parentheses).

# Motivation

When adding `+` to separate trait object paths from bounds in the type grammar, we broke a bunch of code that looked like `1 as uint + 3`. This is because the type parser is greedy and started parsing after `+`. This will allow us
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will allow us what?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops. It'll allow us to add more type operators later in the future.


# Detailed design

The `as` production in the grammar should be `as PATH` or `as (TYPE)` (with the parentheses). `PATH` productions in this context should be parsed as types.

# Drawbacks

Complex types with `as` might become slightly more verbose, and the grammar becomes slightly more complicated.

# Alternatives

The impact of not doing this is that if we extend the type grammar (e.g. with `+`) then we will break existing code.

# Unresolved questions

N/A.