Hacker News Reader

Comment by maxioatic | Hacker News Reader

This little bit, which is not coming in this version but is enabled by it:

> f"" as a short-hand for a format string. For example, f"hello {name}" as a short-hand for the equivalent format_args!() invocation.

I'm excited by. I like the f-string formatting in Python quite a bit.

View on HN

Our original formatting was inspired by C#, this is inspired by Python. We stand on the shoulders of giants, as always.

Didn't realise the C# intermediate step was there, always assumed it was a direct Python influence.

Oh you know, I was confused. It was attributes from C#, not format strings. https://doc.rust-lang.org/stable/reference/attributes.html#a...

> Attributes are modeled on Attributes in ECMA-335, with the syntax coming from ECMA-334 (C#).

I believe Rust took both attributes and format strings from C#. It looks like Python's modern format string syntax dates to 2006, and I think(?) that C#'s format string syntax has been present since its first release in 2002. The PEP adding the modern string formatting syntax links to .NET documentation, although the link is now dead: https://www.python.org/dev/peps/pep-3101/#references

You can even go back earlier : MessageFormat is available in Java since 1997.

TIL! C#'s syntax here looks marginally different than Java's, although that would be completely on-brand. :)

If you don't mind me asking - what goes into implementing a feature like this in Rust? Asking as a complete noob in language design/implementation.

You want to take a look at the RFC process. You could start with the feature we're discussing right now - Implicit arguments in format strings (https://rust-lang.github.io/rfcs/2795-format-args-implicit-i...). Take a look, it's very readable.

There's discussion in the corresponding Github issue of the RFCs repo (https://github.com/rust-lang/rfcs). If the folks who work in that area are supportive, the RFC will be merged. After that someone needs to implement the feature.

Take a look at the Readme in the RFCs repo for more details.

Thanks for the info, appreciate it!

I'm pretty excited about more implicit stuff coming to Rust.

The array/iterator thing always baffled me when I first started learning Rust.

All these tiny DX improvements make the language more accessible and in turn a pleasure to work with!

In general, nindalf's reply is very on point about the mechanics. To expand ever so slightly on this bit:

> If the folks who work in that area are supportive

Rust has teams that make decisions to accept designs in their part of the project. They look at proposals and decide to accept, reject, or postpone them. This process can take a while, depending on all sorts of factors. Sometimes a design may be good, but it may not be the time yet, which is when postponing happens. Sometimes it's a "we don't plan on doing this" and that's when things get rejected. Even if a design is accepted, we don't require that people proposing the design do the implementation work, so if you do propose something and it does get accepted, it may take a while until it actually exists. Furthermore, stuff is in unstable at first, until people can gain experience with the feature, so even after an RFC is accepted, it takes some time until it's "stabilized," at which point it's part of the language proper.

Happy to answer any other specific questions!

Thanks for the detailed response! I checked out the RFC repo posted by nindalf, and I was wondering if you could explain (very briefly) the issue tagging scheme? Do the "A-" tagged issues mean they're active?

Edit: For more context, the README says:

> If you are interested in working on the implementation for an "active" RFC, but cannot determine if someone else is already working on it, feel free to ask (e.g. by leaving a comment on the associated issue).

I went and checked out the issues and couldn't tell which ones were active. (I also don't plan on implementing an RFC, so no worries if this is something that should be apparent to someone more involved.)

"A" is short for "Area", which is something we inherited from Mozilla, IIRC.

I don't think there's a good way to filter on "active", it's mostly like, if you go to the issue and it's open, then it's 'active.' It's a bit odd, because in some sense, for the RFC repo, once the RFC is merged it's "done", and then rest of it is implementation and therefore tracked on the main Rust repo. The "C-tracking-issue" issues are ones that are open and tracking an RFC that's in implementation, https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...

("C" is short for "Category". These prefixes are... well the original ones made sense but I think there was some retconning going on at some point, haha)

I remember hating the idea when the PEP was at first accepted. I hated the thought of refactoring tools breaking, typos leading to empty replacements, etc.

In reality, f-strings work really well and are super elegant. I'm a convert now.

There is also the fstrings crate that emulates this with proc macros: https://crates.io/crates/fstrings

f-strings in Python resolve to strings, but f-strings in Rust will resolve to std::fmt::Arguments IIUC. Not quite the same thing.

Yes, there's a lot of small details that need to be ironed out before we get a clear picture of what the feature might be (remember, there's no guarantee!). There's a reason this is simply reserving the syntax, rather than actually proposing the feature. :)

Of course, I didn't mean to imply any certainty, only that the blog post mentioned that it would likely resolve to format_args! which doesn't return a string but rather std::fmt::Arguments.

Reply on news.ycombinator.com