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

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

Closed
wants to merge 1 commit into from

Conversation

pcwalton
Copy link
Contributor

  • 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

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.


# 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.

@lilyball
Copy link
Contributor

An alternative would be to define a restricted type form that disallows +, and using that restricted form with as expressions, but allowing the full form within parentheses. This is similar to how #92 defines a restricted expression grammar for for/if.

DST is supposed to allow us to make let x: Box<[Box<[u8]>]> = ...; x as &[&[u8]] legal, but &[&[u8]] isn't a PATH. It seems unnecessary to require parentheses for that. The restricted type grammar alternative would allow that while disallowing x as Foo:Bar+Baz.

It may want to disallow : as well, to head off any potential future ambiguity with : as a type ascription operator.

@pcwalton
Copy link
Contributor Author

You can't coerce with as that way. as is not for arbitrary coercions, it's for numeric coercions and trait coercions.

@bstrie
Copy link
Contributor

bstrie commented May 28, 2014

Can you give an example of existing code that this would affect?

@pcwalton
Copy link
Contributor Author

Yes. I did in the RFC.

@lilyball
Copy link
Contributor

@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 Box<[T]> to &[T], even when embedded inside a larger type (because &[T] and Box<[T]> have the same memory representation; I think this was supposed to work for any smart pointer that had no header before the unsized data field). This meant that Vec<Box<[T]>> could coerce to Vec<&[T]>, and was cited back in the discussion over whether to ditch ~[T] entirely in favor of Vec<T> as the only real benefit of the ~[T] type post-DST.

@pcwalton
Copy link
Contributor Author

"as" doesn't do every kind of coercion. It only does two specific kinds of conversions: numeric conversions and trait conversions.

@lilyball
Copy link
Contributor

@pcwalton You cited 1 as uint + 3 as code that will conflict once + is added to the type grammar (BTW, is there an RFC for that that could be cited?). I think @bstrie is asking about existing code that will break if this RFC is implemented (without adding + to the type grammar).

@lilyball
Copy link
Contributor

The DST proposals that introduced the idea of free coercion from Vec<Box<[T]>> to Vec<&[T]> explicitly used the as operator for this coercion.

@pcwalton
Copy link
Contributor Author

OK, I guess it does. But I am opposed to making the type grammar more complicated just for this. PATH is nice and simple, let's keep it simple.

@lilyball
Copy link
Contributor

http://smallcultfollowing.com/babysteps/blog/2014/01/05/dst-take-5/ contains code snippets that use as for this type of DST coercion.

@pcwalton
Copy link
Contributor Author

I doubt much if any existing code will break. The only code that would break would be something like "foo as ~Trait".

@lilyball
Copy link
Contributor

Restricting to PATH means you can't even say foo as &TraitName, which seems rather restrictive (there's no trait bounds on there, so no possible ambiguity).

@pcwalton
Copy link
Contributor Author

foo as &Trait shouldn't be that common anyway now that we autocoerce. But I guess we could make a superset of the type grammar.

@pcwalton
Copy link
Contributor Author

Forget it. I don't want to make the type grammar any more complicated than it is.

@pcwalton pcwalton closed this May 28, 2014
withoutboats pushed a commit to withoutboats/rfcs that referenced this pull request Jan 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants