[philberty]

The biggest problem Rust has is that "no_core" is so poorly understood at this point that i doubt a comprehensive spec is even possible to explain:

1. Type inference taking into account higher ranked trait bounds

  - Slices in libcore work via the Index lang item so its like taking an index operator overload to a range lang item but the generic types in the range need to be unified with the higher ranked trait bound to eventually figure out that they are meant to be of usize.

2. Method resolution its almost a joke at this point how complicated it is in Rust.

  - The autoderef cycle sounds simple when you read this: https://web.mit.edu/rust-lang_v1.25/arch/amd64_ubuntu1404/share/doc/rust/html/book/first-edition/deref-coercions.html

  - But this misses so much extra context information

3. Macro invocations there are really subtle rules on how you treat macro invocations such as this which is not documented at all https://github.com/Rust-GCC/gccrs/blob/master/gcc/rust/expan...

</rant>

Some day I personally want to write a blog post about how complicated and under spec'd Rust is, then write one about the stuff i do like it such as iterators being part of libcore so i don't need reactive extensions.

[ChrisSD]

Hm... I'm not sure I understand. Why would you expect no_core to be specified? It's an implementation detail of rustc, not part of the language.

[philberty]

No core _is_ the Rust language, libcore is just a library which adds the "Rust abstractions" so you can actually write a for loop or create a slice or deref, add or anything else.

Libcore just gets compiled like any other rust crate just it does not have access to abstractions.

For example, you can still write C code without libc because C is a language libc is just a library libcore is pretty much the same. Though Rust makes alot of assumptions that libcore _should_ be there but its possible for it not to be.