From 609031e8abf0505474558fb2d0ccfd76b80de08d Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Thu, 26 Apr 2018 20:16:58 +0200 Subject: [PATCH 01/10] rfc, unreservations: initial version. --- text/0000-unreservations-2018.md | 302 +++++++++++++++++++++++++++++++ 1 file changed, 302 insertions(+) create mode 100644 text/0000-unreservations-2018.md diff --git a/text/0000-unreservations-2018.md b/text/0000-unreservations-2018.md new file mode 100644 index 00000000000..295f4280a30 --- /dev/null +++ b/text/0000-unreservations-2018.md @@ -0,0 +1,302 @@ +- Feature Name: `unreservations` +- Start Date: 2018-04-26 +- RFC PR: +- Rust Issue: + +# Summary +[summary]: #summary + +We unreserve: ++ `pure` ++ `unsize` ++ `sizeof` ++ `alignof` ++ `offsetof` ++ `priv` + +# Motivation +[motivation]: #motivation + +We are currently not using any of the reserved keywords listed in the [summary] +for anything in the language at the moment. We also have no intention of using +the keywords for anything in the future, and as such, we want to unreserve them +so that rustaceans can use them as identifiers. + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +See the [reference-level-explanation]. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +[list of reserved keywords]: https://doc.rust-lang.org/book/second-edition/appendix-01-keywords.html#keywords-currently-in-use + +The keywords listed below are removed from the +[list of reserved keywords] and are longer reserved such that they can be +used as general identifiers. This is done immediately and on edition 2015. + +The keywords to unreserve are: ++ `pure` ++ `unsize` ++ `sizeof` ++ `alignof` ++ `offsetof` ++ `priv` + +# Drawbacks +[drawbacks]: #drawbacks + +The only drawback is that we're not able to use each listed word as a keyword +in the future, without a reservation in a new edition, if we realize that we +made a mistake. + +See the rationale for potential risks with each keyword. + +# Rationale and alternatives +[alternatives]: #alternatives + +There's only one alternative: Not unreserving all listed / some keywords. + +Not unreserving a keyword would make the word unavailable for use as an +identifier. + +## General policy around unreservations + +This RFC establishes a general rationale and policy for keyword unreservation: +*If we are not using a keyword for anything in the language, and we are sure +that we have no intention of using the keyword in the future, then it is +permissible to unreserve a keyword and it is motivated. +Additionally, if there is a desire for a keyword to be used as an identifier, +this can in some cases outweigh very hypothetical and speculative language features.* + +## Rationale for `pure` + +This keyword used to be used for `pure fn`, that is: as an effect. + +[applicative]: http://hackage.haskell.org/package/base-4.11.1.0/docs/Control-Applicative.html#t:Applicative + +When *generic associated types* (GATs) lands, it is likely that people would +like to use this in their [applicative functor][applicative] and monad libraries, +which speaks in favor of unreserving `pure`. This use case explicitly mentioned by [`@ubsan`](https://github.com/ubsan/) who requested that the keyword be unreserved for this purpose. + +### Potential drawbacks + +Examples / The reasons why we might want to keep `pure` reserved are: + +#### 1. Effects + +```rust +pure fn foo(x: Type) -> Type { + ... +} +``` + +Here, `pure` denotes a deterministic function -- but we already have `const` +for more or less the same, and it is unlikely that we would introduce an effect +(or restriction thereof) that is essentially `const fn` but not entirely. +So this use case is unlikely to happen. + +#### 2. Explicit *`Ok`-wrapping* + +```rust +fn foo() -> Result { + if bar() { + pure 0; + } + ... +} +``` + +desugars into: + +```rust +fn foo() -> Result { + if bar() { + return Try::from_ok(0); + } + ... +} +``` + +[Applicative laws]: https://en.wikibooks.org/wiki/Haskell/Applicative_functors#Applicative_functor_laws + +While you might think that Haskell developers would be in favor of this, +that does not seem to be the case. Haskell developers over at +`#haskell @ freenode` were not particularly in favor of this use as `pure` +in this context as `pure` does not respect the [Applicative laws]. +The desugaring is also not particularly obvious when `pure` is used. +If we did add sugar for explicit `Ok`-wrapping, we'd probably go with something +other than `pure`. + +#### Summary + +In both 1. and 2., `pure` can be contextual. +We also don't think that the drawbacks are significant for `pure`. + +## Rationale for `unsize` + +This would be a modifier on types, but we already have `` and we +could have `T: !Sized` so there seems to be no need for keeping `unsized`. + +## Rationale for `sizeof`, `alignof`, and `offsetof` + +We already have [`std::mem::size_of`](https://doc.rust-lang.org/nightly/std/mem/fn.size_of.html) and similar which +are `const fn`s or can be. + +A reason why we might want to keep these reserved is that they already exist in +the standard library, and so we might not want anyone to define these functions, +not because we will use them ourselves, but because it would be confusing, +and so the error messages could be improved saying +*"go look at `std::mem::size_of` instead"*. However, we believe it is better +to allow users the freedom to use these keywords instead. + +## Rationale for `priv` + +Here, `priv` is a privacy / visibility modifier on things like fields, and items. +An example: + +```rust +priv struct Foo; +pub struct Bar { + priv baz: u8 +} +``` + +Since everything is already private by default, `priv` would only be an extra +hint that users can use to be more explict, but serves no other purpose. +Further, we could possibly use `pub(self)` for `priv` instead. + +Permitting `priv` could also be confusing for readers. Consider for example: + +```rust +pub struct Foo { + priv bar: T, + baz: U, +} +``` + +An unsuspecting reader can get the impression that `bar` is private but `baz` +is public. We could of course lint against this mixing, but it does not seem +worth the complexity. + +For these reasons, the current proposal is to unreserve. + +# Prior art +[prior-art]: #prior-art + +Not applicable. + +# Unresolved questions +[unresolved]: #unresolved-questions + +There are none. +All reservations we will do should be resolved before merging the RFC. + +# Appendix +[appendix]: #appendix + +## Reserved keywords we probably don't want to unreserve + +The following keywords are used in the nightly compiler and we are sure +that we want to keep them: + +- `yield` - Generators +- `macro` - Macros 2.0 + +Additionally, there are known potential use cases / RFCs for: + +- `become` - We might want this for guaranteed tail calls. + See [the postponed RFC](https://github.com/rust-lang/rfcs/pull/1888). + +- `typeof` - We might want this for hypothetical usages such as: + ```rust + fn foo(x: impl Bar, y: typeof(x)) { .. } + ``` + +- `do` - We might want this for two uses: + 1. `do { .. } while cond;` loops. + 2. Haskell style do notation: `let az' = do { x <- ax; y <- ay(x); az };`. + +- `abstract` - We might/would like this for: + ```rust + abstract type Foo: Copy + Debug + .. ; + ``` + +- `override` - This could possibly used for: + + OOP inheritance -- unlikely that we'll get such features. + + + specialization -- we do not annotate specialization on the overriding impl + but rather say that the base impl is specializable with `default`, + wherefore `override` does not make much sense. + + + delegation -- this usage was proposed in the delegations pre-RFC: + + ```rust + impl TR for S { + delegate * to f; + + #[override(from="f")] + fn foo(&self) -> u32 { + 42 + } + } + ``` + + which we could rewrite as: + + ```rust + impl TR for S { + delegate * to f; + + override(from f) fn foo(&self) -> u32 { + 42 + } + } + ``` + +## Possible future unreservations + +### `box` + +We use this in nightly for box patterns. +We might want to unreserve this eventually however. + +### `virtual` + +This annotation would be for something like virtual functions (see `dyn`). +However, we already have `dyn`, so why would we need `virtual`? +Assuming the following makes sense semantically (which we do not care about here), +we could easily write: + +```rust +dyn fn foo(..) -> whatever { .. } +``` + +instead of: + +```rust +virtual fn foo(..) -> whatever { .. } +``` + +However, there might be some use case related to specialization. +After specialization is stable, we would like to revisit unreservation of +`virtual`. + +### `final` + +The `final` keyword is currently reserved. It is used in Java to mean two +separate things: +1. "you can't extend (inheritance) this `class`", +2. "you can't mutate this variable", + which we already have for `let` bindings by default. + +A possible use for `final` for us might be for [`Frozen` ](https://internals.rust-lang.org/t/forever-immutable-owned-values/6807). +However, `Frozen` does not have many known uses other than for users who want +to be more strict about things. The word `final` might not be what Java users +would expect it to mean in this context, so it's probably not a good keyword +for `Frozen`. + +However, there might be some use case related to specialization. +After specialization is stable, we would like to revisit unreservation of +`final`. From 47408ea3f2335edd64d9f9eddacb1c5304137391 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Thu, 26 Apr 2018 22:33:34 +0200 Subject: [PATCH 02/10] rfc, unreservations: scratch `priv` from unreservations. --- text/0000-unreservations-2018.md | 66 ++++++++++++++++---------------- 1 file changed, 33 insertions(+), 33 deletions(-) diff --git a/text/0000-unreservations-2018.md b/text/0000-unreservations-2018.md index 295f4280a30..f42eb57786e 100644 --- a/text/0000-unreservations-2018.md +++ b/text/0000-unreservations-2018.md @@ -12,7 +12,6 @@ We unreserve: + `sizeof` + `alignof` + `offsetof` -+ `priv` # Motivation [motivation]: #motivation @@ -42,7 +41,6 @@ The keywords to unreserve are: + `sizeof` + `alignof` + `offsetof` -+ `priv` # Drawbacks [drawbacks]: #drawbacks @@ -151,37 +149,6 @@ and so the error messages could be improved saying *"go look at `std::mem::size_of` instead"*. However, we believe it is better to allow users the freedom to use these keywords instead. -## Rationale for `priv` - -Here, `priv` is a privacy / visibility modifier on things like fields, and items. -An example: - -```rust -priv struct Foo; -pub struct Bar { - priv baz: u8 -} -``` - -Since everything is already private by default, `priv` would only be an extra -hint that users can use to be more explict, but serves no other purpose. -Further, we could possibly use `pub(self)` for `priv` instead. - -Permitting `priv` could also be confusing for readers. Consider for example: - -```rust -pub struct Foo { - priv bar: T, - baz: U, -} -``` - -An unsuspecting reader can get the impression that `bar` is private but `baz` -is public. We could of course lint against this mixing, but it does not seem -worth the complexity. - -For these reasons, the current proposal is to unreserve. - # Prior art [prior-art]: #prior-art @@ -257,6 +224,39 @@ Additionally, there are known potential use cases / RFCs for: ## Possible future unreservations +## `priv` + +Here, `priv` is a privacy / visibility modifier on things like fields, and items. +An example: + +```rust +priv struct Foo; +pub struct Bar { + priv baz: u8 +} +``` + +Since everything is already private by default, `priv` would only be an extra +hint that users can use to be more explict, but serves no other purpose. +Further, we could possibly use `pub(self)` for `priv` instead. + +Permitting `priv` could also be confusing for readers. Consider for example: + +```rust +pub struct Foo { + priv bar: T, + baz: U, +} +``` + +An unsuspecting reader can get the impression that `bar` is private but `baz` +is public. We could of course lint against this mixing, but it does not seem +worth the complexity. + +However, right now (2018-04-26), there is a lot of movement around the module +system. So we would like to wait and discuss unreserving this keyword at some +later time. + ### `box` We use this in nightly for box patterns. From 2bddc3ce21e44338155b5f291a893df6d934c9e3 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Thu, 26 Apr 2018 22:39:00 +0200 Subject: [PATCH 03/10] rfc, unreservations: clarify offsetof wrt. const fn & macro. --- text/0000-unreservations-2018.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/text/0000-unreservations-2018.md b/text/0000-unreservations-2018.md index f42eb57786e..6478f463c62 100644 --- a/text/0000-unreservations-2018.md +++ b/text/0000-unreservations-2018.md @@ -140,7 +140,8 @@ could have `T: !Sized` so there seems to be no need for keeping `unsized`. ## Rationale for `sizeof`, `alignof`, and `offsetof` We already have [`std::mem::size_of`](https://doc.rust-lang.org/nightly/std/mem/fn.size_of.html) and similar which -are `const fn`s or can be. +are `const fn`s or can be. In the case of `offsetof`, we would instead use +a macro `offet_of!`. A reason why we might want to keep these reserved is that they already exist in the standard library, and so we might not want anyone to define these functions, From c44febd90faf5c499a1b5dfd939451dd56953183 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Thu, 26 Apr 2018 22:39:21 +0200 Subject: [PATCH 04/10] rfc, unreservations: fix typo. --- text/0000-unreservations-2018.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-unreservations-2018.md b/text/0000-unreservations-2018.md index 6478f463c62..71c7e00c573 100644 --- a/text/0000-unreservations-2018.md +++ b/text/0000-unreservations-2018.md @@ -141,7 +141,7 @@ could have `T: !Sized` so there seems to be no need for keeping `unsized`. We already have [`std::mem::size_of`](https://doc.rust-lang.org/nightly/std/mem/fn.size_of.html) and similar which are `const fn`s or can be. In the case of `offsetof`, we would instead use -a macro `offet_of!`. +a macro `offset_of!`. A reason why we might want to keep these reserved is that they already exist in the standard library, and so we might not want anyone to define these functions, From 8c4f63f6553b05326d2765de042fe86748b85505 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Fri, 27 Apr 2018 22:31:08 +0200 Subject: [PATCH 05/10] rfc, unreservations: fix unsize -> unsized typos. --- text/0000-unreservations-2018.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/text/0000-unreservations-2018.md b/text/0000-unreservations-2018.md index 71c7e00c573..3fd630d1cfb 100644 --- a/text/0000-unreservations-2018.md +++ b/text/0000-unreservations-2018.md @@ -8,7 +8,7 @@ We unreserve: + `pure` -+ `unsize` ++ `unsized` + `sizeof` + `alignof` + `offsetof` @@ -37,7 +37,7 @@ used as general identifiers. This is done immediately and on edition 2015. The keywords to unreserve are: + `pure` -+ `unsize` ++ `unsized` + `sizeof` + `alignof` + `offsetof` @@ -132,7 +132,7 @@ other than `pure`. In both 1. and 2., `pure` can be contextual. We also don't think that the drawbacks are significant for `pure`. -## Rationale for `unsize` +## Rationale for `unsized` This would be a modifier on types, but we already have `` and we could have `T: !Sized` so there seems to be no need for keeping `unsized`. From d797c44660af86e4ce69ba5be224bc45273b96df Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Sat, 28 Apr 2018 09:17:48 +0200 Subject: [PATCH 06/10] rfc, unreservations: scratch `unsized` from unreservations. --- text/0000-unreservations-2018.md | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/text/0000-unreservations-2018.md b/text/0000-unreservations-2018.md index 3fd630d1cfb..044867b4664 100644 --- a/text/0000-unreservations-2018.md +++ b/text/0000-unreservations-2018.md @@ -8,7 +8,6 @@ We unreserve: + `pure` -+ `unsized` + `sizeof` + `alignof` + `offsetof` @@ -37,7 +36,6 @@ used as general identifiers. This is done immediately and on edition 2015. The keywords to unreserve are: + `pure` -+ `unsized` + `sizeof` + `alignof` + `offsetof` @@ -132,11 +130,6 @@ other than `pure`. In both 1. and 2., `pure` can be contextual. We also don't think that the drawbacks are significant for `pure`. -## Rationale for `unsized` - -This would be a modifier on types, but we already have `` and we -could have `T: !Sized` so there seems to be no need for keeping `unsized`. - ## Rationale for `sizeof`, `alignof`, and `offsetof` We already have [`std::mem::size_of`](https://doc.rust-lang.org/nightly/std/mem/fn.size_of.html) and similar which @@ -225,7 +218,18 @@ Additionally, there are known potential use cases / RFCs for: ## Possible future unreservations -## `priv` +### `unsized` + +This would be a modifier on types, but we already have `` and we +could have `T: !Sized` so there seems to be no need for keeping `unsized`. + +However, `unsized type` or `unsized struct` might be a desirable syntax for +declaring a *dynamically sized type (DST)* or completely unsized type. +Therefore, we will hold of on unreserving `unsized` until we have a better +ideas of how custom DSTs will work and it's clear we don't need `unsized` +as a keyword. + +### `priv` Here, `priv` is a privacy / visibility modifier on things like fields, and items. An example: From 00dde24548bfa0471f414f6db705aef729130b2d Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Wed, 2 May 2018 19:10:35 +0200 Subject: [PATCH 07/10] rfc, unreservations: fix mistakes re. priv. --- text/0000-unreservations-2018.md | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/text/0000-unreservations-2018.md b/text/0000-unreservations-2018.md index 044867b4664..653417c0b59 100644 --- a/text/0000-unreservations-2018.md +++ b/text/0000-unreservations-2018.md @@ -74,7 +74,7 @@ This keyword used to be used for `pure fn`, that is: as an effect. When *generic associated types* (GATs) lands, it is likely that people would like to use this in their [applicative functor][applicative] and monad libraries, -which speaks in favor of unreserving `pure`. This use case explicitly mentioned by [`@ubsan`](https://github.com/ubsan/) who requested that the keyword be unreserved for this purpose. +which speaks in favour of unreserving `pure`. This use case explicitly mentioned by [`@ubsan`](https://github.com/ubsan/) who requested that the keyword be unreserved for this purpose. ### Potential drawbacks @@ -117,9 +117,9 @@ fn foo() -> Result { [Applicative laws]: https://en.wikibooks.org/wiki/Haskell/Applicative_functors#Applicative_functor_laws -While you might think that Haskell developers would be in favor of this, +While you might think that Haskell developers would be in favour of this, that does not seem to be the case. Haskell developers over at -`#haskell @ freenode` were not particularly in favor of this use as `pure` +`#haskell @ freenode` were not particularly in favour of this use as `pure` in this context as `pure` does not respect the [Applicative laws]. The desugaring is also not particularly obvious when `pure` is used. If we did add sugar for explicit `Ok`-wrapping, we'd probably go with something @@ -241,9 +241,13 @@ pub struct Bar { } ``` -Since everything is already private by default, `priv` would only be an extra -hint that users can use to be more explict, but serves no other purpose. -Further, we could possibly use `pub(self)` for `priv` instead. +Since fields are already private by default, `priv` would only be an extra +hint that users can use to be more explicit, but serves no other purpose. +Note however that `enum` variants are not private by default. +Neither are items in `trait`s. Annotating items as `priv` in traits could +potentially be useful for internal `fn`s used in provided `fn` implementations. +However, we could possibly use `pub(self)` instead of `priv`. + Permitting `priv` could also be confusing for readers. Consider for example: From ec7027015ab734a7f5c3c1fc3096b5482c584535 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Wed, 23 May 2018 12:33:07 +0200 Subject: [PATCH 08/10] rfc, unreservations: s/hold of/hold off --- text/0000-unreservations-2018.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-unreservations-2018.md b/text/0000-unreservations-2018.md index 653417c0b59..5b39dacd605 100644 --- a/text/0000-unreservations-2018.md +++ b/text/0000-unreservations-2018.md @@ -44,7 +44,7 @@ The keywords to unreserve are: [drawbacks]: #drawbacks The only drawback is that we're not able to use each listed word as a keyword -in the future, without a reservation in a new edition, if we realize that we +in the future, witld ofut a reservation in a new edition, if we realize that we made a mistake. See the rationale for potential risks with each keyword. @@ -225,7 +225,7 @@ could have `T: !Sized` so there seems to be no need for keeping `unsized`. However, `unsized type` or `unsized struct` might be a desirable syntax for declaring a *dynamically sized type (DST)* or completely unsized type. -Therefore, we will hold of on unreserving `unsized` until we have a better +Therefore, we will hold off on unreserving `unsized` until we have a better ideas of how custom DSTs will work and it's clear we don't need `unsized` as a keyword. From 42d255ade094f196b6f06ee6ee00750f4256c576 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Wed, 23 May 2018 12:34:28 +0200 Subject: [PATCH 09/10] rfc, unreservations: fix introduced typo. --- text/0000-unreservations-2018.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-unreservations-2018.md b/text/0000-unreservations-2018.md index 5b39dacd605..1eb26a7aa30 100644 --- a/text/0000-unreservations-2018.md +++ b/text/0000-unreservations-2018.md @@ -44,7 +44,7 @@ The keywords to unreserve are: [drawbacks]: #drawbacks The only drawback is that we're not able to use each listed word as a keyword -in the future, witld ofut a reservation in a new edition, if we realize that we +in the future, without a reservation in a new edition, if we realize that we made a mistake. See the rationale for potential risks with each keyword. From 17bc1e71c6e98d8496ca7c54f9287d49f5a100a7 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Mon, 28 May 2018 00:31:33 +0200 Subject: [PATCH 10/10] RFC 2421 --- ...000-unreservations-2018.md => 2421-unreservations-2018.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename text/{0000-unreservations-2018.md => 2421-unreservations-2018.md} (98%) diff --git a/text/0000-unreservations-2018.md b/text/2421-unreservations-2018.md similarity index 98% rename from text/0000-unreservations-2018.md rename to text/2421-unreservations-2018.md index 1eb26a7aa30..8b92521bd25 100644 --- a/text/0000-unreservations-2018.md +++ b/text/2421-unreservations-2018.md @@ -1,7 +1,7 @@ - Feature Name: `unreservations` - Start Date: 2018-04-26 -- RFC PR: -- Rust Issue: +- RFC PR: [rust-lang/rfcs#2421](https://github.com/rust-lang/rfcs/pull/2421) +- Rust Issue: [rust-lang/rust#51115](https://github.com/rust-lang/rust/issues/51115) # Summary [summary]: #summary