rust-lang / rfcs Goto Github PK
View Code? Open in Web Editor NEWRFCs for changes to Rust
Home Page: https://rust-lang.github.io/rfcs/
License: Apache License 2.0
RFCs for changes to Rust
Home Page: https://rust-lang.github.io/rfcs/
License: Apache License 2.0
(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).
Tracking issue for postponed PR #57
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.
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 } }
cc #183
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.
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
Variance inference is complete.
What is still missing is:
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.
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.
Tracking issue for postponed PR #52
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.
An RFC to resolve enums with overlapping variant names in an elegant manner.
Tracking issue for postponed PR #94
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
Tracking issue for postponed PR #54
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
Tracking issue for postponed PR #99
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.)
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)
.
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
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()
.
Tracking issue for postponed PR #81
Tracking issue for postponed PR #98
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:
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.
null
Tracking issue for postponed PR #38
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 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
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):
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 */ }
Add a slice operator expr[a..b]
where a
and b
are optional.
expr[..] => expr.as_slice()
expr[a..] => expr.slice_from(a)
expr[..b] => expr.slice_to(b)
expr[a..b] => expr.slice(a, b)
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.
This is largely based on (with lots of copied text) @glaebhoerl's proposal in rust-lang/rust#9912, but with a few changes:
Tracking issue for postponed PR #91
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/".
Tracking issue for postponed PR #36
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.
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.
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 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:
///
/** */
//!
/*! */
#[doc=""]
#[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:
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
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.
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
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:
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.)
RFC 5 does not have an implementation-tracking issue listed.
RFC 11 does not have an RFC PR or implementation-tracking issue listed.
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
This was discussed previously in rust-lang/rust#13126.
Tracking issue for postponed PR #25
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 enum
s 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 enum
s 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
.
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
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
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?
Tracking issue for postponed PR #174
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.