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().

[Jakob5358]

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!

Well if it's explicit like s"" than you can see the difference right. Maybe you think it should be more obvious that it's the struct String that they're creating but I think it's fine, and I'm sure the compiler could give a friendly error explaining it if you use s"" instead of "".

And I don't think this is necessarily for newcomers. I've always found it annoying having to have the .to_owned or .to_string or String::from

[Lokathor]

People can write an s!("foo") macro which does String::from($x) if they've got that many strings.

[orowith2os]

Unsure if it's relevant here, but sounds like it is.

Would it be reasonable to have this work:

let hi: String = "Hello, world!"

So we don't need to always type:

let hi = String::from("Hello, world!")

or:

let hi = "Hello, world!".to_owned()

It's a bit tiring to have to always type this when I could just manually annotate the type and it would get the same end result, which would probably be a simpler way to write it.

[CraftSpider]

Personally, I'm against that kind of implicit conversion, but for the existence of s""/s#"" or similar - string prefixes were reserved on purpose, and this seems a fairly reasonable use-case for them. My one issue is that it makes std more magic, but not sure whether that's a deal-breaker or not. Alternatively, I'd be open to allowing custom string prefixes.