Rename &str::as_bytes() to &str::as_utf8()

[SimonSapin]

This seemed small enough to not be worth an RFC. Please correct me if it’s not.

Similar to how the str::from_bytes function was renamed to str::from_utf8, the &str::as_bytes method should be renamed to something that indicate UTF-8, possibly &str::as_utf8 or &str::as_utf8_bytes.

The &str::bytes and &str::bytes_rev iterators, the ~str::into_bytes method, and the StrBuf equivalent to all of the above should also be renamed accordingly.

[SimonSapin]

The iterator yield one byte at a time, so it probably makes sense for them to keep "bytes" in the name: &str::utf8_bytes and &str::utf8_bytes_rev. In other methods I think it’s redundant: as_utf8 and into_utf8 are enough.

[lilyball]

.as_utf8() suggests it might do some conversion. .as_bytes() tells me it's returning a &[u8] that represents the string.

[SimonSapin]

@kballard I think that as in the name implies something cheap, or even O(1). A conversion method would be to_utf8.

[aturon]

@SimonSapin Yes, small library changes like this don't need to go through the RFC process. +1 for me on the suggested renaming; I think the guidelines are pretty clear about as being cheap.

[liigo]

I don't like this rename, &str is obviously utf-8 encoded, don't need
repeat this any more.

[huonw]

+1 for renaming.

(Outside chance for the iterator: utf8_codeunits, however I'm not a fan of it.)

[lilyball]

@liigo has a good point. &str is, by definition, UTF-8 encoded. as_utf8() would give the impression that this is not true, because it suggests that it's converting from something that is not, in fact, "utf8".

[SimonSapin]

@aturon Does this still sound like something you want?

[aturon]

@SimonSapin Sorry for the slow response. I'm going to mark this as closed, since String stabilization has already landed and made a decision about this issue.

(Personally, I'm happy either way, but we needed to make a decision and I think the stabilization gives a reasonable rationale.)