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] Clarify (and improve) rules for projections and well-formedness #1214

Merged
merged 10 commits into from
Aug 7, 2015
Prev Previous commit
Next Next commit
correct some out of date text that Ralf identified
  • Loading branch information
nikomatsakis committed Aug 6, 2015
commit af2135286944a53fa9ecd5e84713002cfa51309b
17 changes: 9 additions & 8 deletions text/0000-projections-lifetimes-and-wf.md
Original file line number Diff line number Diff line change
Expand Up @@ -710,14 +710,15 @@ lifetime names. Let's start with the rule for fn types:
--------------------------------------------------
R ⊢ for<r..> fn(T1..Tn) -> T0 WF

Basically, this rule says that a `fn` type is *always* WF, regardless
of what types it references. This certainly accepts a type like
`for<'a> fn(x: &'a T)`. However, it also accepts some types that it
probably shouldn't. Consider for example if we had a type like
`NoHash` that is not hashable; in that case, it'd be nice if
`fn(HashMap<NoHash, u32>)` were not considered well-formed. But these
rules would accept it, because `HashMap<NoHash,u32>` appears inside a
fn signature.
Basically, this rule adds the bound lifetimes to the set `R` and then
checks whether the argument and return type are well-formed. We'll see
in the next section that means that any requirements on those types
Copy link
Member

Choose a reason for hiding this comment

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

The next section is "WF checking a trait reference", so I don't know what exactly you are referring to here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@RalfJung

The next section is "WF checking a trait reference", so I don't know what exactly you are referring to here.

Hmm, yes, I meant the "next next section" :) (checking conditions)

which reference bound identifiers are just assumed to hold, but the
remainder are checked. For example, if we have a type `HashSet<K>`
which requires that `K: Hash`, then `fn(HashSet<NoHash>)` would be
illegal since `NoHash: Hash` does not hold, but `for<'a>
fn(HashSet<&'a NoHash>)` *would* be legal, since `&'a NoHash: Hash`
involves a bound region `'a`. See the next section for details.

Note that `fn` types do not require that `T0..Tn` be `Sized`. This is
intentional. The limitation that only sized values can be passed as
Expand Down