Summary
This RFC proposes a syntax for creating owned strings from string literals, focusing on eliminating visual noise and reusing familiar concepts.
Motivation
The difference between a string literal (&'static str
) and an owned String
object is a common source of confusion for new users of the language, and one that experienced users of the language are mostly resigned to. For code like "string literal".to_string()
, the most important detail is the string’s content rather than how it’s stored, yet the visual noise of the method invocation obscures this.
Detailed design
The syntax of string literals is common through the majority of programming languages - a quote character ("
), followed by the contents of the string, followed by a terminating quote character ("
). We can build on this familiarity while taking advantage of advances in text editing capabilities by introducing the notion of a quoted string - an open quote character (“
), followed by the string contents, followed by the closing quote character (”
). The type of such a quoted string expression is String
.
To avoid confusion in terminology, strings surrounded by the old style of quote characters should be referred to as quasi-quoted strings.
It is an error to use two open quote characters or two closing quote characters for a quoted string, but there will be no need to include specific diagnostics for this case. Any such error will be reported by the compiler as an unterminated string.
How we teach this
We can encourage new Rustaceans to write their code using their favourite word processing software (eg. Microsoft Word, LibreOffice, etc.), since they come with full quoting abilities already enabled by default. As users gain proficiency in the language, they can be encouraged to copy and paste quoted strings from their word processor into their preferred text editor.
Drawbacks
For those that refuse to use a modern text editing environment, there may be some pushback until we can provide a list of recommended packages that will make producing quoted strings as straightforward as quasi-quoted strings.
There may be some fonts which do not distinguish between opening and closing quote characters. This would fall under the “Doctor, it hurts when I do this” category of drawbacks.
Alternatives
Previous pre-RFCs have suggested ergonomics improvements through prefixes; one could also envision suffixes, or even midfixes for this task - for example, _
is allowed as a arbitrary separator inside numeric literals (1_000
). We could re-purpose it as a familiar yet meaningful separator for owned string literals ("string "_"literal"
).
We could also stick with the status quo, filling our programs with a forest of .into()
, .to_string()
, and .to_owned()
in an attempt to forget the future that could have been.
Unresolved questions
None at present.