Support formatted string literals

[CodebyCR]

Why is the default #print function working in this why:

 var x = 7;
 Print("The value of x: {0} ", x)

Instated of the formatted Python string or the Swift print function:

In Python:

 var x = 7
 print(f"The value of x: {x} ")

In Swift:

 var x = 7;
 print("The value of x: \(x) ")

In my opinion this represents the future way, and is a lot more intuitive.
If there are no valid reasons for doing so, one should accept this adjustment.

My favoured solution is:

 var x = 7;
 Print("The value of x: {x} ")

and by default '{' and '}' must be masked by '\', if you want to see them in a string.

[jonmeow]

Duplicate of #1801

[jonmeow]

Reading again, I think this is actually a question about formatted string literals, not Print. Retitled and moving to "questions for leads".

[Asaaj]

This is called "string interpolation". Most languages require you to specify this explicitly (using a prefix symbol like $ in C# and f in Python, or a different string enclosing symbol like ` in javascript), though for the most part that has always seemed like a legacy compatibility problem to me. For interoperability and code-sharing between Carbon and C++, I'd guess we'd have to go the explicit route here, too.

[chandlerc]

I'm generally very positive about string interpolation or f-strings etc.

However, I don't think this is a meaningful issue for leads at this point? We would need a proposal to consider actually adding them.

Maybe the question for leads is "are there any fundamental objections or concerns already known without a specific design that would make it not worthwhile to work on a proposal for adding formatted string literals or string interpolation features?"

I think the answer to that is "no", but will let other leads confirm.

(Generally, I also don't think it is necessary for folks to ask this as a question for leads before starting work on a proposal. More useful in my experience is to discuss it on Discord and the forums to collect any concerns the community might have and incorporate those into the eventual proposal.)

[zygoloid]

I agree with @chandlerc -- I see no concerns with adding this kind of feature, and it seems like useful functionality to support. We'll need to see a specific proposal that explores the design details in order to deliver useful feedback beyond that.

[chandlerc]

I agree with @chandlerc -- I see no concerns with adding this kind of feature, and it seems like useful functionality to support. We'll need to see a specific proposal that explores the design details in order to deliver useful feedback beyond that.

Is it useful to keep an issue for leads here though? There doesn't seem to be anything for us to say "yes" or "no" or ... to?

[jonmeow]

Filed #2005 to track the need for a proposal in this space.

[chandlerc]

Also closing the issue for now. We can always re-open it if some aspect of the proposal ends up having concerns or controversy.