Tracking issue for make_ascii_{upper,lower}case

[alexcrichton]

This is a tracking issue for the unstable ascii feature in the standard library. These functions have the somewhat odd naming scheme of make_* (not found elsewhere in the standard library). The utility with &mut str is also somewhat questionable as there's not a lot of support for that in the standard library.

Overall this probably just largely needs a decision.

[alexcrichton]

cc @SimonSapin

[Gankra]

Minor correction: Rc::make_unique is another example of this naming.
Unstable of course.
On Aug 13, 2015 10:09 AM, "Alex Crichton" notifications@github.com wrote:

cc @SimonSapin https://github.com/SimonSapin

—
Reply to this email directly or view it on GitHub
#27809 (comment).

[SimonSapin]

There should be a way to do this operation without allocating. I don’t have a strong opinion on in place with &mut str v.s. consuming and returning String (as in the now-deprecated OwnedAsciiExt trait), except that the former is sometimes slightly less convenient. (You need three statements instead of one expression.)

[Ms2ger]

I don't like the &mut approach, but that might be because I'm not yet used to it.

[nox]

I would prefer consuming the given String too.

[murarth]

The &mut str approach has the advantage that it can be used to convert an arbitrary subslice within a String. If the consuming String approach is adopted instead, the ability to do that would be lost.

[SimonSapin]

You can always iterate the &mut u8 bytes in a string and map them to upper case one by one (which is what the &mut str impl does). (Although yes, doing so is unsafe and it’s nice to have a safe wrapper for it.)

[barosl]

As for naming, something like to_ascii_uppercase_in_place might be better. It clearly states the purpose of the function, and it also has a bonus point that this function will be sorted around the more canonical to_ascii_uppercase function. The drawback is that the name is much longer, but I think it won't be much a problem as the usage of this operation might be much rarer.

[barosl]

But I also think make_ makes sense if we go the route of consuming String and returning String. In that case, we would lose a safe wrapper on slices, but that's for another decision.

[SimonSapin]

+1 for *_in_place if we keep &mut self mutating method (as opposed to self consuming methods).

[SimonSapin]

If the libs team has the bandwidth, I’d like to nominate this for discussion. To sum up, options are:

• Current semantics, maybe with a rename
• Change these methods to into_ascii_*case(self) -> Self. This may need to be a separate trait.

Both are equally general: at worst if all you have is a &mut String, you can do the mem::replace dance to use methods that consume and return an owned String.

[SimonSapin]

Also, it’s possible to build this out of tree:

for byte in &mut (bytes: Vec<u8>) {
    *byte = byte.to_ascii_lowercase()
}

for byte in unsafe { (s: String).as_mut_vec() } {
    *byte = byte.to_ascii_lowercase()
}

… though it would be nice to encapsulate the unsafety in the String case.