Make `str` a library type (and lang item)

[aturon]

With DST, there is no longer any reason that str needs to be a primitive type; it can instead be defined in the library as a newtype wrapper around [u8]. (It will, of course, still need to be a lang item for string literals to work).

The main visible consequence of this change would be the removal of several prelude traits in favor of inherent methods -- so it has some impact on library stabilization.

It may also be that the name could/should be revisited if it is no longer primitive.

[aturon]

cc @nick29581 @nikomatsakis

[aturon]

Nominating. I think this is P-backcompat-libs, but not 1.0 (since we can live with the extension traits if we have to).

[japaric]

Interesting! I tried this once before, and found an ICE which has been already solved. I'll give it another try soon (only the library side, I don't know how to do the lang item part)

[aturon]

@japaric Awesome! Let me know if I can do anything to help.

[nikomatsakis]

When we discussed things at the work week where we planned out DST, we did intend for str to be a library type.

[japaric]

@aturon As a test I created the Str([u8]) type out of tree (see the docs). I removed StrPrelude and replaced it with inherent methods on the Str type, moved the from_utf8 free function into Str, and also checked that the doctests pass. The only issue that I found in the process was #19037 which already got fixed.

About the implementation process, I guess these are the steps to take?

• Add a str lang item for the string literals ("foo")
• Add the str([u8]) struct, mark it with the str lang item, remove StrPrelude, add inherent methods
• Remove the compiler support that glues the built-in str to string literals.
• Remove the rest of the compiler support for the built-in str (like being specially treated as a DST?)

I really hope that we would be able to split the work like that (although probably parts 2 and 3 will have to get done at the same time), otherwise it's going to be a big patch. Also, depending if we want to rename str to Str (since it would no longer be a built-in/primitive type), we may end up with a massive code churn and downstream breakage (probably not worth it).

[nikomatsakis]

@japaric what do you mean by "adding a str lang item" as a step? that seems like it's... a line in a table, or perhaps you mean something more?

[japaric]

@nikomatsakis I meant modify the compiler to allow something like this:

#[lang = "str"]
struct Str([u8]);

let foo: &'static Str = "Hello world!";

Or can I simply do:

// libcore/str.rs
struct str([u8]);

impl str { fn contains__(&self, needle: &str) -> bool { /* .. */ } }

// and this will just work?
let foo: &'static str = "Hello!";
assert!(foo.contains__("el"));

[nikomatsakis]

@japaric no, we will definitely need a lang item, but it seems like at least some of the steps you listed must be done atomically (adding the lang item; changing the type of literals to use this lang item). We could (and should) move the extension traits over separately, once that transition is done.

Is this the staging you had in mind?

[nikomatsakis]

(If nothing else, we probably want to do a snapshot before changing the extension traits)

[nikomatsakis]

Oh, and: I think that we should not change the name of str as part of this issue. If we want to do that, that's something to consider separately. I'd certainly want a stronger justification (which I think may exist, but that's another story) than "it's a lang item and hence only partially built-in to the compiler".