4 ms·

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.

nindalf 5y ago
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-identifiers.html 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 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.
- maxioatic 5y ago
  Thanks for the info, appreciate it!
- k__ 5y ago
  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!
steveklabnik 5y ago
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!
- maxioatic 5y ago
  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.)
  - steveklabnik 5y ago
    "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%3Aopen+rfc+label%3AC-tracking-issue 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)

nindalf 5y ago

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-identifiers.html 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 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.

maxioatic 5y ago
Thanks for the info, appreciate it!
k__ 5y ago
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!

steveklabnik 5y ago

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!

maxioatic 5y ago
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.)
- steveklabnik 5y ago
  "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%3Aopen+rfc+label%3AC-tracking-issue 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)