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

[martinvuyk]

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

[bgreni]

The ubiquitous use and utility of format is precisely why we cannot intentionally shortcut the implementation for Mojo. It needs to work the same as Python programmers expect it to eventually. However as you mentioned the standard is quite complex and given it doesn't quite align with the short term priorities for Mojo it's unlikely to be prioritized anytime soon I would bet.

I agree having trivial stand in support for now would be nice though!

[laszlokindrat]

Thanks for opening this ticket! I agree that f-strings are one of the most useful features in Python. StringLiteral is eventually going to become non-materializable with String as the materialization target, so I wouldn't worry too much about it in this context.

At the same time, I strongly agree with @bgreni here: eventually we must comply with the f-string semantics dictated by Python. This doesn't mean, however, that we couldn't hill climb this. I would suggest that we start with something simple, like String.format[*Ts: Stringable](*args: *Ts) without any ability for format specification, then extend to String.format[*Ts: Stringable, *Us: Stringable](*args: *Ts, **kwargs: *Stringable). This would already enable some useful functionality. It might also require some compiler improvements; if we can't prioritize those, we can fall back to just String.format(*args: String, **kwargs: String).

Then I would start looking at implementing the builtin format function, along with a related trait along these lines:

trait StringFormattable:  # name to be bike shedded
    fn __format__(self, format_spec: StringSlice) -> String: ...
    fn __format__(self) -> String: ...   # overload to work around some current issues with default stringslice values

Note that we already have a Formattable trait, but it requires a slightly lower level API. We need to think about how these could compose. @ConnorGray you have been doing some work in this area, WDYT?

[rd4com]

@laszlokindrat excellent, looks like a nice plan !

@bgreni 👍

[rd4com]

Hello @laszlokindrat , i pushed a change in #2771 for the simple {0} + *args 👍

i feel that if anybody have a better understanding on how it works with python, they could do the implementations.

This is challenging and need to be done the right way !

I observed that if we could assign to a slice, it would be easier: res[13:16] = str(args[i])