Remove string [] indexing

[huonw]

It is byte indexing (not character indexing) which is encouraging poor UTF-8 hygiene, and the behaviour can be regained either with the .bytes() iterator, or just s.as_bytes() to get a &[u8] view (at zero cost).

[huonw]

nominating

[bstrie]

Seconded. In a UTF-8 world, what we think of as a "string" is emphatically not an array.

[thestinger]

+1, it's rarely correct to index strings at all, and especially not by bytes

[thestinger]

I would also be for removing the len method and using as_bytes().len() instead. Strings don't need to implement the Container trait as they're not actually a container of a specific type.

[sfackler]

+1

[pongad]

I volunteer to work on this. By the way, we do have a function to decode character points right?

[pongad]

~str in patterns seems to be blocking this. I'll try work on that and come back to this later.

[huonw]

Why would string pattern matching affect string indexing?

[pongad]

I'm not sure myself. After removing string indexing, I got "internal
compiler errors". Tracked it to #[lang=uniq_str_eq].

On Wed, Mar 5, 2014 at 7:05 PM, Huon Wilson [email protected]:

Why would string pattern matching affect string indexing?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12710#issuecomment-36810589
.

[nikomatsakis]

This will probably fall out of the changes we plan for DST, or at
least could easily do so.

[pnkfelix]

Accepted for 1.0, P-backcompat-libs.

[lilyball]

@thestinger Removal of [] indexing makes some small sense, but removal of len() is too far. If you remove len() then you have to remove slice() as well, and that's just too painful (going through .as_bytes() to slice loses all information about whether the result is valid utf-8 and is extremely wasteful to get back to &str).

[brson]

Any hints what has to change in the code to fix this? I took a peek but got lost in trait lookups, while I thought slice indexing was built-in.

[nikomatsakis]

@brson hmm, I think the PRIMARY thing that has to change is middle::ty::ty_index(), which says that a str is indexable to type u8

[nikomatsakis]

the function middle::mem_categorization::element_kind could also be updated to remove that case

[brson]

Thanks, @nikomatsakis. I've started a patch.

[alexchandel]

Rust strings feel much less intuitive to me than Python's str. I'm fine with UTF-8, but in Python str/strings are unicode and indexing/slicing them yields a unicode character. Python has a separate bytes class for encoded strings, whether they're UTF-8, 16, or 32 encoded, and uses the b"" syntax to designate byte-string literals versus u"" for unicode string literals.

[huonw]

in Python str/strings are unicode

So are Rust strings, the major difference is we do not disguise the underlying representation.

(Also, it's not exactly clear what your point is? If it is that indexing should be removed, then @brson's patch #15085 is being tested as we speak.)