[Feature Request] [mojo-lang] [proposal] Make fstring formatting a priority and define what features will be available

[martinvuyk]

Review Mojo's priorities

• [X] I have read the roadmap and priorities and I believe this request falls within the priorities.

What is your request?

Fstring formatting i.e. f"my text with an embedded value: {some_var}, it's so simple" is one of the best features of Python IMO, it helps really simplify dealing with strings. What I don't like, is how complicated the "".format() PEP specification is...

What I would propose is that we simplify things and let the programmer decide how to represent their types. Make it so that f strings are syntax sugar for string concatenation.

If someone wants to represent, say, an int's hex value, then they should just do f"some hex_value: {hex(10)}", instead of the StringLiteral.format() method needing to have a bunch of edge cases and different handcoded support for each stdlib type...

We can also simplify things even more by saying that f"my text with an embedded value: {some_var}, it's so simple" generates code that looks like ("my text with an embedded value: " + (some_var) + ", it's so simple") that way chained f strings would be simpler to implement.

var a  = f"Just imagining that {f"I can chain {f"my text with an embedded value: {some_var}, it's so simple"} that I can almost taste"} the absolute joy of writing in this language"

Would codegen into

var a = "Just imagining that" + ("I can chain  " + ("my text with an embedded value: " + (some_var) + ", it's so simple") + "that I can almost taste") + "the absolute joy of writing in this language"

What is your motivation for this change?

Adding support for Python fstrings is important. But I think we shouldn't implement it exactly the same. We could do a StringLiteral.format() equal to Python's, but I don't think fstrings should have templating capabilities since that just overcomplicates things and we can leave those cases to StringLiteral.format() anyway

Any other details?

No response