-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
RFC: "as" should be "as PATH" or "as (TYPE)" #96
Conversation
|
||
# 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
An alternative would be to define a restricted type form that disallows DST is supposed to allow us to make It may want to disallow |
You can't coerce with |
Can you give an example of existing code that this would affect? |
Yes. I did in the RFC. |
@pcwalton I don't know what the current plan is anymore, but one of the benefits DST was supposed to bring was the ability to have free conversions from |
"as" doesn't do every kind of coercion. It only does two specific kinds of conversions: numeric conversions and trait conversions. |
The DST proposals that introduced the idea of free coercion from |
OK, I guess it does. But I am opposed to making the type grammar more complicated just for this. |
http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-take-5/ contains code snippets that use |
I doubt much if any existing code will break. The only code that would break would be something like "foo as ~Trait". |
Restricting to |
|
Forget it. I don't want to make the type grammar any more complicated than it is. |
Summary
The
as
production in the grammar should beas PATH
oras (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 like1 as uint + 3
. This is because the type parser is greedy and started parsing after+
. This will allow usDetailed design
The
as
production in the grammar should beas PATH
oras (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.