String literal

[ElectricCoffee]

Constantly writing "foo".to_string() and String::from("foo") gets tedious after a while.

So I'm proposing a String literal, it could be something as simple as s"foo", @"foo", or even s!"foo" similar to vec![1, 2, 3].

Pros: String gets less verbose, and it comes across just as clear.

Cons: String gets special treatment

[Ixrec]

For reference, I believe the most recent discussion on the string literals problem was: https://internals.rust-lang.org/t/pre-rfc-allowing-string-literals-to-be-either-static-str-or-string-similar-to-numeric-literals/5029 Sadly this problem didn't quite fit into this year's ergonomics initiative.

[burdges]

It frequently improves performance slightly if the code for which you need the .to_string() could take a T: AsRef<str> instead of String, which notably includes T = Cow<'static,str>.

As an aside, I'm curious : Is .to_owned()/.to_string() immediately followed by reserve(..) optimized into a single allocation? If not, there is a case for a ToString::to_string_with_reserve method, but really one should focus on that optimization there so that to_owned() and hence Cow<'a,[T]> benefit.

[scottmcm]

New string prefixes are a breaking change in the presence of macro_rules, IIRC. Is that the kind of thing that could be changed in an epoch? s"Hello" seems perfectly reasonable...

[ElectricCoffee]

It also fits the style of raw strings, being r"Hello", so it's not exactly foreign syntax.

The logic behind s!"Hello" would basically be to allow " to be a legal delimiter in macros, thus allowing users to write their own string macros. Much like how Scala has custom string interpolation.

[steveklabnik]

Long ago, rust had ~"" for what we'd now call a String literal. It caused a lot of people to use String where they didn't need to. Many people are opposed to a single-character String literal for this reason.

[warlord500]

as much as this might be nice for new comers, i really don't think this would be a good idea!
all this would do is delay the inevitable. their eventually going to have to understand the difference between
str and String. dealing with that might actually make things now much harder!

[deifactor]

FWIW, one place where I tend to want this is when I've got something like:

map.get(key).cloned().unwrap_or("some default".to_owned())

and other similar cases where I want to use a string literal as a default value.

[ElectricCoffee]

FWIW, one place where I tend to want this is when I've got something like:

map.get(key).cloned().unwrap_or("some default".to_owned())

and other similar cases where I want to use a string literal as a default value.

Personally, I prefer just using .into() wherever possible.
Granted, it doesn't convey intent as easily, as .into() could mean anything, but it's shorter than .to_owned() and .to_string().