This is a proposal for type parameter lists that come well before the
actual generic items. Example:

type <T: Unwieldy+Traits+Go+Here,
      U: Even+More+Traits> {
  fn foo(t: T) -> U { ... }
  fn bar(u: U) -> T { ... }
}

Tracking issue for postponed PR #122

RFC 5 does not have an implementation-tracking issue listed.

RFC 11 does not have an RFC PR or implementation-tracking issue listed.

This was discussed previously in rust-lang/rust#13126.

Tracking issue for postponed PR #25

Take for example this snippet from https://github.com/rust-lang/rfcs/blob/7443c30a25b7ddc10a36ee3c3344596cb60ed549/active/0003-opt-in-builtin-traits.md#implementation-plan:

Here is a loose implementation plan that @flaper87 and I worked out.

Who is the first person here? Sure, I can look it up, but for these RFCs an informal writing style is undesirable.

Can we please mandate a formal writing style, or at the very least ban first person writing?

This is largely based on (with lots of copied text) @glaebhoerl's proposal in rust-lang/rust#9912, but with a few changes:

• I formalized the idea of "contexts" by using GHC's roles.
• I used this role system to include user-defined pointers and data structures.
• I dropped contravariance for simplicity. This may have been a bad idea, but it's unclear how useful contravariance is.

Tracking issue for postponed PR #91

null

Tracking issue for postponed PR #38

Per the concerns mentioned on PR #19 by @bill-myers and @cmr, one option to help library authors remember to implement Send and Share would be a lint that warns you about builtin traits that you could have implemented but did not. I envision this being part of a series of lints that enforce best practices for libraries (and I could even see having them warn by default in library mode, but perhaps not app mode). I intend to add discussion of this to the PR.

Issue by tuncer
Tuesday Jan 22, 2013 at 22:14 GMT

For earlier discussion, see rust-lang/rust#4578

This issue was labelled with: A-an-interesting-project, A-typesystem, B-RFC, I-wishlist, P-low in the Rust repository

See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1507.htm and http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1397.htm

Issue by bstrie
Tuesday May 28, 2013 at 12:36 GMT

For earlier discussion, see rust-lang/rust#6782

This issue was labelled with: B-RFC in the Rust repository

Currently we have six forms of doc comments:

• outer line ///
• outer block /** */
• inner line //!
• inner block /*! */
• outer attribute #[doc=""]
• inner attribute #[doc="";]

Ideally this would be reduced to one, but if two are necessary then that's fine. It's perfectly acceptable to not cater to every miniscule style convention. Here is my proposal:

1. Remove the direct attribute forms, since their unwieldiness was why we introduced the comment syntax in the first place. This reduces to four.
2. Select either line or block, and remove the other. This reduces to two.
3. Remove the inner form if possible. If we can find some special way to document modules without requiring a special syntax just for that, then so much the better.

Alternatively, we could conclude that it's simply too much trouble to have special forms for doc comments and just stick with the attribute forms. This would be somewhat uglier, but more consistent with the rest of the language

Rendered view

Tracking issue for postponed PR #174

Tracking issue for postponed PR #52

Over the past couple of years, we've had a number of rust tickets that hypothesize "if we had feature X, we could design an API like this", where we have an idea, but we're not ready for an RFC. For example:

• generators
• higher order kinds
• associated items, which I believe is only written down in @nikomatsakis blog.

We also have had a number of these thought experiments in IRC, which were never captured and probably forgotten.

Does it still make sense to track these features in the rust issue tracker? It's rather easy for these threads to run on for years and for them to get lost in the noise. I think it might make more sense to have those conversations over in this repository. That would make these a bit easier to discover and track their current state of conceptualization. It would also make it easier to close these conversations down if we decide to never go in that direction.

Issue by ghost
Sunday Mar 17, 2013 at 02:56 GMT

For earlier discussion, see rust-lang/rust#5417

This issue was labelled with: A-libs, A-traits, B-RFC in the Rust repository

Since I've been doing some work with the deriving code in libsyntax, I thought I'd solicit opinions on adding a new trait to libcore:

trait Enum {
    static fn enumerate(blk: &fn(Self) -> bool);
}

Obviously, this would be most useful for enums with only nullary variants, but other enumerable types could take advantage of it as well (bool::all_values currently serves the same purpose).

This would make it possible to write

// enum Dir { North, East, South, West }
for Enum::enumerate |dir: Dir| { ... }

instead of

for [North, East, South, West].each |dir| { ... }

A standard implementation for enums with only nullary variants would be made available through #[deriving(Enum)], and a default method (or utility trait/impl until those are working) would be provided for obtaining all the values in a vector. It might be beneficial to have a static fn cardinality() -> Option<uint> method on the trait as well.

If the trait name is too easily confused with the keyword, another option is Enumerable.

There is a long discussion on rust-lang/rust#4160 discussing the possibility of adding explicit slice operators to the language. Clearly if this is to be done, it requires an RFC and explicit discussion and approval.

I think the consensus on that thread was for the proposal found in this comment (full disclosure, by me):

1. Add a Slice trait:

   trait Slice<T> {
       fn as_slice<'a>(&'a self) -> &'a [T];
       fn slice_from(&'a self, from: uint) -> &'a [T];
       fn slice_to(&'a self, to: uint) -> &'a [T];
       fn slice(&'a self, from: uint, to: uint) -> &'a [T];
   }
   
   trait MutSlice<T> : Slice<T> { /* as above but with mut qualifiers */ }
   

2. Add a slice operator expr[a..b] where a and b are optional.

   • The operator autoderefences, like indexing.
   • For fixed-length vectors, its effect is built-in.
   • For other types, it is translated to a call to the appropriate trait method:
     • expr[..] => expr.as_slice()
     • expr[a..] => expr.slice_from(a)
     • expr[..b] => expr.slice_to(b)
     • expr[a..b] => expr.slice(a, b)

3. Do we have something for mutable slices? Perhaps expr[mut a..b]? These come up less frequently but nonetheless it seems useful, particularly for fixed-length vectors since otherwise there remains no explicit syntax for slicing one that does not rely on coercion.

I'm still roughly in favor of this, though I think I would change the syntax expr[..] to expr[], just because it's shorter. Note though that with DST one can simply do &*vec to get the as_slice() notation.

When an RFC is rejected today, the proposed details might be interesting tomorrow.
Currently for this purpose the submitter needs to keep his branch around forever.

I propose to merge interesting/controversial rejected RFC for archival purposes in a subdirectory "rejected/".

Rendered

Tracking issue for postponed PR #120

As I noted here, the current definition for "lifetime input position" does not make it 100% clear that when it says that certain lifetimes in an impl are in input position, that is solely for the purposes of inferring output lifetimes for other parts of the impl header, and has absolutely no effect on the method definitions within the impl.

I hope to have a PR to fix this and a few other typos shortly.

Issue by huonw
Saturday Jul 13, 2013 at 10:05 GMT

For earlier discussion, see rust-lang/rust#7773

This issue was labelled with: A-an-interesting-project, A-attributes, A-traits, B-RFC, I-wishlist in the Rust repository

This would allow one to emulate conventional OO inheritance (to some degree) automatically, instead of requiring a lot of boilerplate, e.g.

trait A {
  fn foo(&self);
  fn bar(&self);
  fn baz(&self);
}

struct Basic {
   some_field: int
}

impl A for Basic {
  fn foo(&self) {}
  fn bar(&self) {}
  fn baz(&self) {}
}

struct Extended {
   inner: Basic,
   extra: int
}

#[delegate_to(inner)]
impl A for Extended {
  fn foo(&self) {} // new version of `foo`
}
/* automatically created:
  fn bar(&self) { self.inner.bar() }
  fn baz(&self) { self.inner.baz() }
*/

This isn't possible as a syntax extension, since the methods in a trait are not known at expansion time. And methods returning Self would have to be implemented by hand.

I guess this is similar to default methods. I think it would allow traits to replace the closures-in-structs pattern entirely (e.g. the ast visitor), since currently it's not easily possible to write Visitor { visit_expr: |e, (a,v)| { ... }, .. some_non_default_visitor } (i.e. replacing only the visit_expr method of a visitor defined elsewhere, which is not the default_visitor()) in terms of default methods only (this came up in my attempt to replace the struct visitors in rustc::middle::lint with @Aatch's trait+default-methods based one).

Related:

• similar discussion about subtyping & structs
• discussion about this proposal
• "Delegation" in Kotlin is very similar, but this proposal is possibly more flexible

A super-wishlist behaviour would be turning any recursive method calls (i.e. calling a method from the same trait) on the base type into calls on the extended type, so:

impl A for Base {
   fn foo(&self) {
       if some_condition { self.bar() }
   }
   fn bar(&self) {}
}

struct Extended { base: Base }

#[delegate_to(base)]
impl A for Extended {}

// is equivalent to

impl A for Extended {
   fn foo(&self) {
       if some_condition { self.bar() }  
       // different to plain self.inner.bar(), which is `if some_condition { self.base.bar() }`
   }
   fn bar(&self) { self.base.bar() }
}

(This is possibly possible by recording "a trait-self" against which to call methods from the same trait, I don't know.)

Tracking issue for postponed PR #54

Issue by bstrie
Thursday Apr 25, 2013 at 17:59 GMT

For earlier discussion, see rust-lang/rust#6065

This issue was labelled with: A-typesystem, B-RFC, I-papercut in the Rust repository

I filed #6045 before I realized that you have to make useless traits to implement methods on primitives. However, we already use lang items to identify core::char as the "canonical" char module, yes? Is it possible then to allow impls directly upon char from within core::char, since we know that it won't have anonymous impls anywhere else? This is what I'd like to be able to do:

impl char {
    fn anything() { ... }
}

without having to make a useless trait first:

trait UselessCharTrait {
    fn anything();
}

impl UselessCharTrait for char {
    fn anything() { ... }
}

This is somewhat more pertinent now that #3048 is WONTFIX.

literally the best RFC related to literals.

Tracking issue for postponed PR #143

trait T {
    fn foo(@mut self);
}

struct S {
    unused: int
}

impl T for S {
    fn foo(@mut self) {
    }
}

fn main() {
    let s = @S { unused: 0 };
    let s2 = s as @T;
    let s3 = s2 as @T;
}

error: failed to find an implementation of trait @T for T

cc #183

Pretty

Tracking issue for postponed PR #186

Issue by visionmedia
Thursday Jun 06, 2013 at 14:12 GMT

For earlier discussion, see rust-lang/rust#6974

This issue was labelled with: B-RFC in the Rust repository

I'm not sure how this would play out with internals or if it wouldn't provide enough information to the compiler, but instead of something like:

impl Shape for Circle {
    fn draw(&self, s: Surface) { do_draw_circle(s, *self); }
}

If possible it would be great to just do something like:

fn draw(self: Circle, s: Surface) {
  // ...
}

Where circle.draw(surface) is just sugar for draw(circle, surface).

As we know, the simpler an issue is the more opinions there are on the matter. Many of the RFCs proposed here get flooded with bikeshedding before the important discussions on "is this a good idea", "does this make sense", etc can take place.

Given it is usually at least 2 weeks until an RFC can make it on the schedule for a weekly meeting, can we save the first week for discussion on the design issues of an RFC, before we get all the opinions on the word/symbol/number-of-spaces/brace-position stuff?

Even if it is just an informal practice.

Tracking issue for postponed PR #36

Tracking issue for postponed PR #57

RFC for improving SIMD support.

First time I've done something like this, so apoligies for anything I may have gotten wrong.

Acknowledgements to @jensnockert's post here: http://blog.aventine.se/2013/07/16/my-vision-for-rust-simd.html for forming the basis of this RFC

Tracking issue for postponed PR #15

Rendered view: https://github.com/SimonSapin/rfcs/blob/matches-macro/active/0000-matches-macro.md

Please note: This is different from the if let proposal. I believe the two proposals are complementary rather than competing.

Tracking issue for postponed PR #163

Issue by nikomatsakis
Wednesday Sep 26, 2012 at 18:51 GMT

For earlier discussion, see rust-lang/rust#3598

This issue was labelled with: A-typesystem, B-clarifying, B-RFC, E-mentor, P-high in the Rust repository

UPDATE

Variance inference is complete.

What is still missing is:

• applying results of variance inference to type parameters -- this is an expressiveness issue
• applying results of variance inference to trait matching (#5781) -- this is a soundness issue

ORIGINAL

Today, we treat all type parameters as invariant, but infer variance for region parameters. We can use that same code which infers the variance for region parameters to infer the suitable variance for type parameters if we like.

Alternatively, if we decide that inference here is too magical, we could require explicit declaration of variance. In that case, i'd favor covariance as the default, and the possibility to write struct Foo<mut T> to indicate an invariant type parameter T (which can appear in mutable locations). This seems more intuitive than the usual + and -. We probably don't need a notation for contravariance, but in that case perhaps fn T (to indicate a type parameter that appears only in function arguments, far and away the most common place to have a contravariant type parameter).

Still, I think I favor inference. It's inline with what we do for regions and I think it will basically match up with user expectations.

Issue by jensnockert
Tuesday Jun 11, 2013 at 13:58 GMT

For earlier discussion, see rust-lang/rust#7059

This issue was labelled with: B-RFC in the Rust repository

Code like this should work, preferably picking the most specialized function (and/or just picking a random one, or the first that matches &c. or just throw a warning)

pub fn abs<T: Signed>(value: T) -> T { value.abs() }
pub fn abs<T: Ord + Zero + Neg<T>>(v: T) -> T { if v < Zero::zero() { v.neg() } else { v } }

Using Rust as a glue language in place of C, or in addition to C, is quite popular and an area of a lot of potential for Rust, but right now we're not catering to it.

One aspect of Rust's embeddability is knowing what the ABI is. Although we don't want to have a stable ABI yet, we can start defining clearly what it is to make embedders live's easier.

Create a C header file called rust.h. This contains struct definitions useful for interop with Rust as well as declarations of C-ABI functions in the standard library that are intended for embedding and interop - it's the embedding API.

Then extend our test infrastructure to execute "embedding tests": a) build a rust library, b) build a C exe that links to it, and execute.

Some structs that are probably useful: strings, vectors, slices, a few different form of Option that have a guaranteed representation, closures, procs.

cc @wycats

Tracking issue for postponed PR #98

In #33 (comment), @cmr said:

Also, I don't think this deserves an RFC. RFCs should be for language changes and changes to items marked #[stable], I think.

It wasn’t clear to me based on https://mail.mozilla.org/pipermail/rust-dev/2014-March/008973.html (see also #31) if #33 required an RFC or not. It generated more discussion that I would have expected, but that discussion could just as well have happened in the main issue tracker.

When you need to follow this process

You need to follow this process if you intend to make "substantial"
changes to the Rust distribution. What constitutes a "substantial"
change is evolving based on community norms, but may include the following.

• Any semantic or syntactic change to the language that is not a bugfix.

This changes libraries, but not the language.

• Changes to the interface between the compiler and libraries,
  including lang items and intrinsics.

Nope.

• Additions to std

Change, not addition.

Some changes do not require an RFC:

• Rephrasing, reorganizing, refactoring, or otherwise "changing shape
  does not change meaning".

Unsure about that one. Does MaybeOwned have the same "meaning" as ~str?

• Additions that strictly improve objective, numerical quality
  criteria (warning removal, speedup, better platform coverage, more
  parallelism, trap more errors, etc.)

I could make up a micro-benchmark with a numerical result, but there are also drawbacks.

• Additions only likely to be noticed by other developers-of-rust,
  invisible to users-of-rust.

This will definitely be noticed by users.

This is a rough draft to see whether something like this should be done. I'd appreciate feedback on how the technical details could look like, since I do not know a lot about the compiler internals myself.

Tracking issue for postponed PR #56

Proposing to add Invalid trait and use it for Option<T> space optimization. This is an alternative to RFC #36.

Tracking issue for postponed PR #41

According to the meeting notes on RFC 48 (PR #136), at the end, @nikomatsakis says that he wants to make a change for private supertraits. Presumably this means changing the RFC to allow them. However, the RFC was merged without any such change.

(a) At present, the format of the RFC header (excluding the start date line which is fine) is like this:

- RFC PR #: 19
- Rust Issue #: 13231

• RFC PR #: 19
• Rust Issue #: 13231

(b) Given that we are using GitHub, this would be more immediately useful like this:

- RFC PR: #19
- Rust Issue: mozilla/rust#13231

• RFC PR: #19
• Rust Issue: rust-lang/rust#13231

(c) For optimal clarity and portability across GitHub, we could extend the RFC PR to be an absolute reference:

- RFC PR: rust-lang/rfcs#19
- Rust Issue: mozilla/rust#13231

• RFC PR: #19
• Rust Issue: rust-lang/rust#13231

(d) For absolute portability, we could use URLs:

- RFC PR: https://github.com/rust-lang/rfcs/pull/19
- Rust Issue: https://github.com/mozilla/rust/issue/13231

• RFC PR: #19
• Rust Issue: https://github.com/mozilla/rust/issue/13231

(e) Possibly with friendly labels (mix this with the first three options to produce (e.a), (e.b) and (e.c); below, (e.c) is shown):

- RFC PR: [rust-lang/rfcs#19](https://github.com/rust-lang/rfcs/pull/19)
- Rust Issue: [mozilla/rust#13231](https://github.com/mozilla/rust/issue/13231)

• RFC PR: rust-lang/rfcs#19
• Rust Issue: mozilla/rust#13231

I suggest (c) or (e.c).

As people modify the text of their RFCs, they are sometimes force pushing changes up to github, which can cause the history of previous iterations of the rfc to be lost (which is not so bad), and it also can cause the comment history to be lost on the rfc's ticket (which is much more severe).

See e.g. discussion on PR 10

RFC 0001 should be amended to explicitly advise people to not force push changes to their forks of the rfcs repository when developing an rfc.

An RFC to resolve enums with overlapping variant names in an elegant manner.

Tracking issue for postponed PR #94

When an RFC is accepted, it is modified to include the PR number and the issue number for the tracking issue on rust-lang/rust. Since RFCs are markdown rather than plain text, these two numbers should be hyperlinked to the actual PR/issue they refer to.

For example, when RFC 18 was accepted (in b683d2e), it was modified like so:

-- RFC PR #:
-- Rust Issue #:
+- RFC PR #: 79
+- Rust Issue #: 14309

This should instead have been:

-- RFC PR #:
-- Rust Issue #:
+- RFC PR #: [79](https://github.com/rust-lang/rfcs/pull/79)
+- Rust Issue #: [14309](https://github.com/rust-lang/rust/issues/14309)

Issue by huonw
Monday Jul 08, 2013 at 14:16 GMT

For earlier discussion, see rust-lang/rust#7649

This issue was labelled with: A-attributes, B-RFC in the Rust repository

If there was a #[no_override] attribute that made it impossible to override a default method, there would be very little need for the FooUtil traits (with this attribute default methods would have almost exactly the same properties as *Util, except the seperate trait can be imported separately). i.e.

trait Foo {
  fn bar(&self);

  #[no_override]
  fn call_bar(&self) { self.bar(); }
}
impl Foo for int {
  fn bar(&self) {}

  fn call_bar(&self) {} // error!
}

This would provide a workaround for #5898 that is a proper solution in its own right.

Issue by metajack
Friday Apr 05, 2013 at 21:04 GMT

For earlier discussion, see rust-lang/rust#5748

This issue was labelled with: A-syntaxext, B-RFC in the Rust repository

Currently you can not pass @ or ~ or @mut to a macro by itself, but this would be useful in a few cases. I tried doing this to add Clone trait implementations without copying the code:

macro_rules! ptr_clone_impl(
    ($p:something) => {
        impl<T:Clone> Clone for $p T {
            #[inline(always)]
            fn clone(&self) -> $p T { $p (**self).clone() }
        }
    }
)

ptr_clone_impl!(~)
ptr_clone_impl!(@)
ptr_clone_impl!(@mut)

But as far as I can tell there is no fragment specifier that will work for those tokens.

Taken from: https://mail.mozilla.org/pipermail/rust-dev/2014-June/010318.html

The below are a good set of questions. We should strive to update our process documentation so that one can derive the answers to questions like these.

(I expect there to be some answers, perhaps all, posted in the email thread linked above.)

1. Which of the following does submitting an RFC imply?
   1. We should implement this right away.
   2. We should implement this before 1.0.
   3. We should implement this whenever we feel like it.
2. Some RFC PRs get closed and tagged with the "postponed" label. Does this
   mean:
   1. It's too early to implement this proposal, or
   2. it's too early to evaluate this proposal?
3. Are the designs outlined by RFCs supposed to be "incremental" or
   "final"? I.e.,
   1. First of all we should make this change, without implying anything
      about what happens after that; or
   2. This is how it should look in the final version of the language?
4. If someone submits an RFC, does she imply that "I am planning to
   implement this", or, if an RFC is accepted, does that mean "anyone who
   wants to can feel free to implement this"?
5. The reviewing process is somewhat opaque to me.
   1. What determines which RFCs get reviewed in a given weekly meeting?
   2. As an observer, how can I tell which RFCs are considered to be in a
      ready-for-review or will-be-reviewed-next state?
   3. What if the author of the reviewed RFC isn't a participant in the
      meetings?
   4. parenthetical: (I might also ask "what determines which RFC PRs get attention from the
      team?", but obviously the answer is "whatever they find interesting".)

Tracking issue for postponed PR #81

Issue by bjz
Sunday Jun 02, 2013 at 00:22 GMT

For earlier discussion, see rust-lang/rust#6894

This issue was labelled with: B-RFC, P-high in the Rust repository

This issue formalizes @pcwalton's RFC on the mailing list. This was also discussed in the 2013-05-14 meeting and in #6087. Steps towards this have already been made in #6462.

Whilst this is not a high priority change at the moment (understandably there are far bigger fish to fry), this is a semi-common question on the IRC and I think it's good if we have some place to redirect questions to.

Instead of the current:

Real::pi::<float>()

this change would allow you to do:

float::pi()

or

type T = float;
T::pi()

This could also allow for neat things like a generic SizeOf trait: T::size_of(), which is far nicer than the current size_of::<T>(). Or maybe there could be an Init trait for default initializers: T::init().

Issue by nikomatsakis
Wednesday Feb 13, 2013 at 21:40 GMT

For earlier discussion, see rust-lang/rust#4920

This issue was labelled with: A-traits, A-typesystem, B-RFC, I-cleanup, P-backcompat-lang in the Rust repository

Right now, operator "methods" proceed according to the same logic as any other method. But this leads to surprising results like this: https://gist.github.com/bstrie/4948410

Also, operators are already handled somewhat specially because we auto-ref their arguments. This means that you can write val1-of-my-linear-type == val2-of-my-linear-type and it doesn't move or do anything creepy (to call eq explicitly, in contrast, you'd write val1-of-my-linear-type.eq(&val2-of-my-linear-type)).

I think method lookup for operators should never apply any automatic transformations to the receiver or arguments, other than the current auto-ref behavior (which means that a OP b is kind of implicitly (&a).OP(&b))

@pcwalton I expect you in particular might have an opinion about this.

Rendered view

Tracking issue for postponed PR #99