[philberty]

I'm personally pretty excited to see where this goes. It could be the best way for gccrs to version itself. There are some immediate aspects I am pretty interested in relation to the spec:

1. Method resolution

2. Unstable?

In particular is it going to define lang items?

3. DST's

Rust has strange things like:

```

let a:&str = "str";

let b:&str = &"str";

```

Which is valid since str is a DST. Although slices and dyn trait are DST they have more strict rules there.

4. Qualified paths

There are more subtle things like qualified paths such as this testcase which could be argued is valid https://github.com/rust-lang/rust/blob/master/src/test/ui/qu... but there was some discussion on zulip which clarifies it: https://rust-lang.zulipchat.com/#narrow/stream/122651-genera...

5. Never type

TLDR: Overall I think its important at some point to start isolating what is the language outside of what version of libcore your running.

[veber-alex]

> let b:&str = &"str";

This has nothing to do with DST but with type coercion.

The type of `b` is `&&str` but you requested the type to be `&str` which is fine as the compiler can coerce from `&&str` to `&str` in this case.

In the same way you can write

  let b: &i32 = &&&&1;

and it will compile fine

[mjw1007]

Better documentation for method resolution than the Reference has would be nice. But at the moment the Ferrocene spec just says

> 6.12:3 A method call expression is subject to method resolution

with "method resolution" marked as being a missing link.