RFC: Attributes in formal function parameter position #2565

Robbepop · 2018-10-15T09:53:31Z

This RFC proposes to add attributes in formal function parameter position.

Rendered
Tracking issue: rust-lang/rust#60406

SimonSapin · 2018-10-15T09:57:07Z

I think that the underscore prefix convention is well established and that #[unused] is not needed. The rest of this proposal still applies to procedural macros, though I don’t have a strong opinion on that.

petrochenkov · 2018-10-15T10:04:49Z

Some questions to answer:

Whether macro attributes are supported.
Whether cfg is supported.
Whether attributes in fn types are supported (type F = fn(#[attr] param: Type); and type F = fn(#[attr] Type);).
Future compatibility with attributes on patterns #[attr] Pat and types #[attr] Type.

text/2540-formal-function-parameter-attributes.md

Centril · 2018-10-15T10:14:12Z

Thank you for and congratulations on writing your first RFC!
I and others have left some thoughts for you to address :)

Centril · 2018-10-15T10:23:59Z

A use case for this with proptest could be to enable the following:

#[proptest]
fn prop_my_property(#[types(T = u8 | u16)] elem: Vec<T>, ...) {
    ...
)

This would replace T with u8 and u16...

Also:

#[proptest]
fn prop_my_property(#[strat = 0..100] elem: usize, ...) {
    ...
)

Tho I'd probably formulate this instead as:

#[proptest]
#[proptest::types(T = u8 | u16)] 
fn prop_my_property<T>(elem: Vec<T>, ...) {
    ...
)

#[proptest]
fn prop_my_property(elem in 0..100usize, ...) { // this unfortunately won't parse
    ...
)

Robbepop · 2018-10-15T10:28:39Z

I think that the underscore prefix convention is well established and that #[unused] is not needed. The rest of this proposal still applies to procedural macros, though I don’t have a strong opinion on that.

You might be right about that. It was just an idea I had. We do not need to have language defined attributes for now.

Robbepop · 2018-10-15T10:32:43Z

Some questions to answer:

* Whether macro attributes are supported.

* Whether `cfg` is supported.

* Whether attributes in fn types are supported (`type F = fn(#[attr] param: Type);` and `type F = fn(#[attr] Type);`).

* Future compatibility with attributes on patterns `#[attr] Pat` and types `#[attr] Type`.

Good points!

I haven't concretely thought about macro attributes but I think that they should be supported for convenience if that doesn't mean too much extra work. I cannot see the end of the scope for this to be honest.

I have no clear answer for the cfg support. What do you think?

I would postpone the attributes in fn types for another RFC since at least to my understanding this would force having attributes be part of the type system.

What do you mean by the future compatibility with attributes on patterns and types? So what shouldn't be compatible with them in the future? I am sorry that I do not understand.

Robbepop · 2018-10-15T10:45:59Z

A use case for this with proptest could be to enable the following:

#[proptest]
fn prop_my_property(#[types(T = u8 | u16)] elem: Vec<T>, ...) {
    ...
)

This would replace T with u8 and u16...

Also:

#[proptest]
fn prop_my_property(#[strat = 0..100] elem: usize, ...) {
    ...
)

Tho I'd probably formulate this instead as:

#[proptest]
#[proptest::types(T = u8 | u16)] 
fn prop_my_property<T>(elem: Vec<T>, ...) {
    ...
)

#[proptest]
fn prop_my_property(elem in 0..100usize, ...) { // this unfortunately won't parse
    ...
)

Thank you for those interesting ideas around the use case.
I will implement them in the RFC in the motivation section.

text/2540-formal-function-parameter-attributes.md

petrochenkov · 2018-10-15T21:11:43Z

@Robbepop

I haven't concretely thought about macro attributes but I think that they should be supported for convenience if that doesn't mean too much extra work.

Macro attributes are supported only in a relatively small subset of attribute positions, so it's better to start with not supporting them.

I have no clear answer for the cfg support. What do you think?

cfg is generally supported in all attribute positions (IIRC it's under-implemented for generic parameters though), so it's better to support it.

I would postpone the attributes in fn types for another RFC since at least to my understanding this would force having attributes be part of the type system.

It wouldn't have any effect on type system, no more than attributes on function definitions.
Also, function types basically share the grammar with trait methods (at least on 2015 edition), so it may be more convenient to support attributes in them, at least for named parameters fn(#[attr] param: Type) (see below).

petrochenkov · 2018-10-15T21:23:41Z

What do you mean by the future compatibility with attributes on patterns and types?

Right now we support attributes on arbitrary expressions, so it's quite possible that we'll eventually support attributes on arbitrary types and patterns as well.

In this case what the attribute is attached to in

fn f(#[attr] PAT: TYPE) {}

, to the pattern, or to the whole parameter?

I think we'll be able to reattach the attributes from parameters to patterns if pattern attributes become available, but I'm not entirely sure (macros?).

In this sense fn f(#[attr] &self) looks pretty suspicious, since &self is not a pattern, but I guess we'll be able to treat this as a sugar and reattach the attribute in the desugared form #[attr] self: &Self.

That's why fn f(#[attr] TYPE) (attribute on anonymous parameter) looks suspicious as well, so I suggest to not support this, so we don't have to think about attributes on types in addition to all the other issues.

nielsle · 2018-10-16T05:20:35Z

I think that I would prefer the following

#[ignore_args]
fn foo( #[ignore] bar: bool);

over the following

fn foo( #[ignore] bar: bool);

The first version is longer, but the scope of the macro is more clear. But then again this distinction is probably out of scope for the RFC.

kennytm · 2018-10-16T15:30:02Z

In this case what the attribute is attached to in
fn f(#[attr] PAT: TYPE) {}
, to the pattern, or to the whole parameter?

Just wanna note that this thing already exists:

fn main() {
    match 3 {
        #[cfg(windows)] 
        3 => println!("a"),
        #[cfg(unix)] 
        3 => println!("b"),
        _ => println!("c"),
    }
}

and the attribute is applied to the whole arm, not the pattern.

joshtriplett · 2018-10-17T15:44:10Z

I'm in favor of allowing attributes on parameters.

Please do drop the bits about replacing the _ convention with #[unused], though.

Centril · 2018-10-17T15:46:43Z

Please do drop the bits about replacing the _ convention with #[unused], though.

I believe it's not part of the proposal; rather, it is a hypothetical use case that some person could do in a procedural macro.

Robbepop · 2018-10-17T18:25:39Z

In this case what the attribute is attached to in
fn f(#[attr] PAT: TYPE) {}
, to the pattern, or to the whole parameter?
Just wanna note that this thing already exists:
fn main() {
    match 3 {
        #[cfg(windows)] 
        3 => println!("a"),
        #[cfg(unix)] 
        3 => println!("b"),
        _ => println!("c"),
    }
}
and the attribute is applied to the whole arm, not the pattern.

So should we do the same for the parameter attributes so that the attribute is for the PAT and the TYPE?

Robbepop · 2018-10-17T18:26:15Z

Please do drop the bits about replacing the _ convention with #[unused], though.

I believe it's not part of the proposal; rather, it is a hypothetical use case that some person could do in a procedural macro.

I should reformulate this to cause no misunderstandings.

kennytm · 2018-10-18T05:31:52Z

@Robbepop Attributes typically aren't transitive. The attribute is applied to the parameter itself, not the pattern nor the type.

Robbepop · 2019-03-04T17:03:21Z

@Robbepop I've taken the liberty to polish the RFC a bit, provide clarifications, and so on. I hope that's OK. Could you give the changes a look? After that I think we should be in a position to move ahead with this proposal.

I am so sorry - saw this just now.
Thank you for taking this over!

Edit:
@Centril I have read through the entire updated RFC. This got huge over time and it looks really good to me.
Thanks so much for taking it over and pushing it!

Centril · 2019-03-05T07:31:03Z

This RFC represents an extension to where attributes are permitted in the language. The extension is small, consistently applied, and has notable use cases as per comments in this RFC. I believe that the extension of attributes to other places in the language affords users to encode the EDSLs that they like. As this RFC is an important step on that road, I think we should move ahead with it and so therefore, I propose that we:

@rfcbot merge

rfcbot · 2019-03-05T07:31:03Z

Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged team members:

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

scottmcm · 2019-04-18T19:55:24Z

Sounds reasonable to me, though the implementation will need to be careful to avoid adding a bunch of new "we forgot to block that attribute in that particular position" mistakes.

@rfcbot reviewed

rfcbot · 2019-04-18T20:25:29Z

🔔 This is now entering its final comment period, as per the review above. 🔔

nikomatsakis · 2019-04-18T20:27:07Z

NB: I tagged for @aturon as they are temporarily inactive.

rfcbot · 2019-04-28T20:29:04Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

The RFC will be merged soon.

Centril · 2019-04-30T10:10:25Z

Huzzah! This RFC has been merged!

Tracking issue: rust-lang/rust#60406

@Robbepop

Stabilize `param_attrs` in Rust 1.39.0 # Stabilization proposal I propose that we stabilize `#![feature(param_attrs)]`. Tracking issue: #60406 Version: 1.39 (2019-09-26 => beta, 2019-11-07 => stable). ## What is stabilized It is now possible to add outer attributes like `#[cfg(..)]` on formal parameters of functions, closures, and function pointer types. For example: ```rust fn len( #[cfg(windows)] slice: &[u16], #[cfg(not(windows))] slice: &[u8], ) -> usize { slice.len() } ``` ## What isn't stabilized * Documentation comments like `/// Doc` on parameters. * Code expansion of a user-defined `#[proc_macro_attribute]` macro used on parameters. * Built-in attributes other than `cfg`, `cfg_attr`, `allow`, `warn`, `deny`, and `forbid`. Currently, only the lints `unused_variables` and `unused_mut` have effect and may be controlled on parameters. ## Motivation The chief motivations for stabilizing `param_attrs` include: * Finer conditional compilation with `#[cfg(..)]` and linting control of variables. * Richer macro DSLs created by users. * External tools and compiler internals can take advantage of the additional information that the parameters provide. For more examples, see the [RFC][rfc motivation]. ## Reference guide In the grammar of function and function pointer, the grammar of variadic tails (`...`) and parameters are changed respectively from: ```rust FnParam = { pat:Pat ":" }? ty:Type; VaradicTail = "..."; ``` into: ```rust FnParam = OuterAttr* { pat:Pat ":" }? ty:Type; VaradicTail = OuterAttr* "..."; ``` The grammar of a closure parameter is changed from: ```rust ClosureParam = pat:Pat { ":" ty:Type }?; ``` into: ```rust ClosureParam = OuterAttr* pat:Pat { ":" ty:Type }?; ``` More generally, where there's a list of formal (value) parameters separated or terminated by `,` and delimited by `(` and `)`. Each parameter in that list may optionally be prefixed by `OuterAttr+`. Note that in all cases, `OuterAttr*` applies to the whole parameter and not just the pattern. This distinction matters in pretty printing and in turn for macros. ## History * On 2018-10-15, @Robbepop proposes [RFC 2565][rfc], "Attributes in formal function parameter position". * On 2019-04-30, [RFC 2565][rfc] is merged and the tracking issue is made. * On 2019-06-12, a partial implementation was completed. The implementation was done in [#60669][60669] by @c410-f3r and the PR was reviewed by @petrochenkov and @Centril. * On 2019-07-29, [#61238][61238] was fixed in [#61856][61856]. The issue fixed was that lint attributes on function args had no effect. The PR was written by @c410-f3r and reviewed by @matthewjasper, @petrochenkov, and @oli-obk. * On 2019-08-02, a bug [#63210][63210] was filed wherein the attributes on formal parameters would not be passed to macros. The issue was about forgetting to call the relevant method in `fn print_arg` in the pretty printer. In [#63212][63212], written by @Centril on 2019-08-02 and reviewed by @davidtwco, the issue aforementioned was fixed. * This PR stabilizes `param_attrs`. ## Tests * [On Rust 2018, attributes aren't permitted on function parameters without a pattern in trait definitions.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-2018.rs) * [All attributes that should be allowed. This includes `cfg`, `cfg_attr`, and lints check attributes.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-allowed.rs) * [Built-in attributes, which should be forbidden, e.g., `#[test]`, are.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-builtin-attrs.rs) * [`cfg` and `cfg_attr` are properly evaluated.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) * [`unused_mut`](https://github.com/rust-lang/rust/blob/46f405ec4d7c6bf16fc2eaafe7541019f1da2996/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) and [`unused_variables`](https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/lint-unused-variables.rs) are correctly applied to parameter patterns. * [Pretty printing takes formal parameter attributes into account.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-pretty.rs) ## Possible future work * Custom attributes inside function parameters aren't currently supported but it is something being worked on internally. * Since documentation comments are syntactic sugar for `#[doc(...)]`, it is possible to allow literal `/// Foo` comments on function parameters. [rfc motivation]: https://github.com/rust-lang/rfcs/blob/master/text/2565-formal-function-parameter-attributes.md#motivation [rfc]: rust-lang/rfcs#2565 [60669]: #60669 [61856]: #61856 [63210]: #63210 [61238]: #61238 [63212]: #63212 This report is a collaborative work with @Centril.

@Robbepop

Stabilize `param_attrs` in Rust 1.39.0 # Stabilization proposal I propose that we stabilize `#![feature(param_attrs)]`. Tracking issue: rust-lang#60406 Version: 1.39 (2019-09-26 => beta, 2019-11-07 => stable). ## What is stabilized It is now possible to add outer attributes like `#[cfg(..)]` on formal parameters of functions, closures, and function pointer types. For example: ```rust fn len( #[cfg(windows)] slice: &[u16], #[cfg(not(windows))] slice: &[u8], ) -> usize { slice.len() } ``` ## What isn't stabilized * Documentation comments like `/// Doc` on parameters. * Code expansion of a user-defined `#[proc_macro_attribute]` macro used on parameters. * Built-in attributes other than `cfg`, `cfg_attr`, `allow`, `warn`, `deny`, and `forbid`. Currently, only the lints `unused_variables` and `unused_mut` have effect and may be controlled on parameters. ## Motivation The chief motivations for stabilizing `param_attrs` include: * Finer conditional compilation with `#[cfg(..)]` and linting control of variables. * Richer macro DSLs created by users. * External tools and compiler internals can take advantage of the additional information that the parameters provide. For more examples, see the [RFC][rfc motivation]. ## Reference guide In the grammar of function and function pointer, the grammar of variadic tails (`...`) and parameters are changed respectively from: ```rust FnParam = { pat:Pat ":" }? ty:Type; VaradicTail = "..."; ``` into: ```rust FnParam = OuterAttr* { pat:Pat ":" }? ty:Type; VaradicTail = OuterAttr* "..."; ``` The grammar of a closure parameter is changed from: ```rust ClosureParam = pat:Pat { ":" ty:Type }?; ``` into: ```rust ClosureParam = OuterAttr* pat:Pat { ":" ty:Type }?; ``` More generally, where there's a list of formal (value) parameters separated or terminated by `,` and delimited by `(` and `)`. Each parameter in that list may optionally be prefixed by `OuterAttr+`. Note that in all cases, `OuterAttr*` applies to the whole parameter and not just the pattern. This distinction matters in pretty printing and in turn for macros. ## History * On 2018-10-15, @Robbepop proposes [RFC 2565][rfc], "Attributes in formal function parameter position". * On 2019-04-30, [RFC 2565][rfc] is merged and the tracking issue is made. * On 2019-06-12, a partial implementation was completed. The implementation was done in [rust-lang#60669][60669] by @c410-f3r and the PR was reviewed by @petrochenkov and @Centril. * On 2019-07-29, [rust-lang#61238][61238] was fixed in [rust-lang#61856][61856]. The issue fixed was that lint attributes on function args had no effect. The PR was written by @c410-f3r and reviewed by @matthewjasper, @petrochenkov, and @oli-obk. * On 2019-08-02, a bug [rust-lang#63210][63210] was filed wherein the attributes on formal parameters would not be passed to macros. The issue was about forgetting to call the relevant method in `fn print_arg` in the pretty printer. In [rust-lang#63212][63212], written by @Centril on 2019-08-02 and reviewed by @davidtwco, the issue aforementioned was fixed. * This PR stabilizes `param_attrs`. ## Tests * [On Rust 2018, attributes aren't permitted on function parameters without a pattern in trait definitions.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-2018.rs) * [All attributes that should be allowed. This includes `cfg`, `cfg_attr`, and lints check attributes.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-allowed.rs) * [Built-in attributes, which should be forbidden, e.g., `#[test]`, are.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-builtin-attrs.rs) * [`cfg` and `cfg_attr` are properly evaluated.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) * [`unused_mut`](https://github.com/rust-lang/rust/blob/46f405ec4d7c6bf16fc2eaafe7541019f1da2996/src/test/ui/rfc-2565-param-attrs/param-attrs-cfg.rs) and [`unused_variables`](https://github.com/rust-lang/rust/blob/master/src/test/ui/lint/lint-unused-variables.rs) are correctly applied to parameter patterns. * [Pretty printing takes formal parameter attributes into account.](https://github.com/rust-lang/rust/blob/master/src/test/ui/rfc-2565-param-attrs/param-attrs-pretty.rs) ## Possible future work * Custom attributes inside function parameters aren't currently supported but it is something being worked on internally. * Since documentation comments are syntactic sugar for `#[doc(...)]`, it is possible to allow literal `/// Foo` comments on function parameters. [rfc motivation]: https://github.com/rust-lang/rfcs/blob/master/text/2565-formal-function-parameter-attributes.md#motivation [rfc]: rust-lang/rfcs#2565 [60669]: rust-lang#60669 [61856]: rust-lang#61856 [63210]: rust-lang#63210 [61238]: rust-lang#61238 [63212]: rust-lang#63212 This report is a collaborative work with @Centril.

matklad · 2021-02-03T12:35:54Z

One thing I've noticed which wasn't obvious to me during RFC discussion. The following is now on the path of the least resistance:

fn f(
    foo: Foo,
    #[cfg(feature = "bar")]
    bar: Bar,
)

However, it breaks additiveness of the bar feature and otherwise creates code with non-trivially feature-dependent APIs. This is harder to work with and understand for humans (as such cfg necessary infects callers). This is also hard for tools -- implementing "change signature" refactor for this seems challenging.

Less obvious, but more maintainable option is to do this:

fn f(
    foo: Foo,
    bar: Bar,
) {
..
}

struct Bar {
  #[cfg(feature = "bar")]
  imp: RealImpl,
  #[cfg(not(feature = "bar"))]
  imp: DummyZstImpl,
}

TedDriggs · 2021-02-09T14:22:21Z

@matklad would a clippy lint against using cfg on parameters be a sufficient deterrent?

Create 2540-formal-function-parameter-attributes.md

cf0b8ec

Centril added the T-lang Relevant to the language team, which will review and decide on the RFC. label Oct 15, 2018

Robbepop changed the title ~~RFC: attributes in formal function parameter position~~ RFC: Attributes in formal function parameter position Oct 15, 2018

Robbepop mentioned this pull request Oct 15, 2018

Allow attributes in logical parameter position rust-lang/rust#55033

Closed

petrochenkov reviewed Oct 15, 2018

View reviewed changes

text/2540-formal-function-parameter-attributes.md Outdated Show resolved Hide resolved

Centril reviewed Oct 15, 2018

View reviewed changes

Update 2540-formal-function-parameter-attributes.md

67f2e2e

Centril reviewed Oct 15, 2018

View reviewed changes

text/2540-formal-function-parameter-attributes.md Outdated Show resolved Hide resolved

Robbepop added 4 commits October 15, 2018 13:12

Update 2540-formal-function-parameter-attributes.md

4529f89

Update 2540-formal-function-parameter-attributes.md

76da521

Update 2540-formal-function-parameter-attributes.md

051be99

Update 2540-formal-function-parameter-attributes.md

66d944b

Centril added the I-nominated label Oct 18, 2018

pnkfelix self-assigned this Oct 25, 2018

Centril added the I-nominated label Feb 27, 2019

Centril removed the I-nominated label Mar 5, 2019

rfcbot added proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. disposition-merge This RFC is in PFCP or FCP with a disposition to merge it. labels Mar 5, 2019

rfcbot added final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. and removed proposed-final-comment-period Currently awaiting signoff of all team members in order to enter the final comment period. labels Apr 18, 2019

rfcbot added the finished-final-comment-period The final comment period is finished for this RFC. label Apr 28, 2019

rfcbot removed the final-comment-period Will be merged/postponed/closed in ~10 calendar days unless new substational objections are raised. label Apr 28, 2019

Centril mentioned this pull request Apr 30, 2019

Tracking issue for RFC 2565, "Attributes in formal function parameter position" rust-lang/rust#60406

Closed

4 tasks

RFC 2565

59dc355

Centril merged commit 26ed27b into rust-lang:master Apr 30, 2019

dtolnay mentioned this pull request Aug 3, 2019

Tracking issue for syn 1.0 dtolnay/syn#687

Closed

This was referenced Aug 27, 2019

Stabilize param_attrs in Rust 1.39.0 c410-f3r/rust#1

Closed

Stabilize param_attrs in Rust 1.39.0 rust-lang/rust#64010

Merged

bryanburgers mentioned this pull request Feb 6, 2020

Allow argument documentation graphql-rust/juniper#525

Closed

ecstatic-morse mentioned this pull request Feb 19, 2020

Replace #[rustc_args_required_const(n)] with per-argument attr rust-lang/rust#69282

Closed

not-my-profile mentioned this pull request Nov 25, 2021

RFC: Attributes in function return type position #3201

Open

tigregalis mentioned this pull request Jul 24, 2022

rustdoc support for per-parameter documentation rust-lang/rust#57525

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RFC: Attributes in formal function parameter position #2565

RFC: Attributes in formal function parameter position #2565

Robbepop commented Oct 15, 2018 •

edited by Centril

Loading

SimonSapin commented Oct 15, 2018

petrochenkov commented Oct 15, 2018

Centril commented Oct 15, 2018

Centril commented Oct 15, 2018

Robbepop commented Oct 15, 2018

Robbepop commented Oct 15, 2018

Robbepop commented Oct 15, 2018

petrochenkov commented Oct 15, 2018

petrochenkov commented Oct 15, 2018

nielsle commented Oct 16, 2018

kennytm commented Oct 16, 2018

joshtriplett commented Oct 17, 2018

Centril commented Oct 17, 2018

Robbepop commented Oct 17, 2018

Robbepop commented Oct 17, 2018

kennytm commented Oct 18, 2018

Robbepop commented Mar 4, 2019 •

edited

Loading

Centril commented Mar 5, 2019

rfcbot commented Mar 5, 2019 •

edited by cramertj

Loading

scottmcm commented Apr 18, 2019

rfcbot commented Apr 18, 2019

nikomatsakis commented Apr 18, 2019

rfcbot commented Apr 28, 2019

Centril commented Apr 30, 2019

matklad commented Feb 3, 2021 •

edited

Loading

TedDriggs commented Feb 9, 2021

RFC: Attributes in formal function parameter position #2565

RFC: Attributes in formal function parameter position #2565

Conversation

Robbepop commented Oct 15, 2018 • edited by Centril Loading

SimonSapin commented Oct 15, 2018

petrochenkov commented Oct 15, 2018

Centril commented Oct 15, 2018

Centril commented Oct 15, 2018

Robbepop commented Oct 15, 2018

Robbepop commented Oct 15, 2018

Robbepop commented Oct 15, 2018

petrochenkov commented Oct 15, 2018

petrochenkov commented Oct 15, 2018

nielsle commented Oct 16, 2018

kennytm commented Oct 16, 2018

joshtriplett commented Oct 17, 2018

Centril commented Oct 17, 2018

Robbepop commented Oct 17, 2018

Robbepop commented Oct 17, 2018

kennytm commented Oct 18, 2018

Robbepop commented Mar 4, 2019 • edited Loading

Centril commented Mar 5, 2019

rfcbot commented Mar 5, 2019 • edited by cramertj Loading

scottmcm commented Apr 18, 2019

rfcbot commented Apr 18, 2019

nikomatsakis commented Apr 18, 2019

rfcbot commented Apr 28, 2019

Centril commented Apr 30, 2019

matklad commented Feb 3, 2021 • edited Loading

TedDriggs commented Feb 9, 2021

Robbepop commented Oct 15, 2018 •

edited by Centril

Loading

Robbepop commented Mar 4, 2019 •

edited

Loading

rfcbot commented Mar 5, 2019 •

edited by cramertj

Loading

matklad commented Feb 3, 2021 •

edited

Loading