From 6e5ef11228d33e949d78e68ec578b5a66df82ebc Mon Sep 17 00:00:00 2001 From: Joshua Liebow-Feeser Date: Sat, 18 Aug 2018 10:26:24 -0700 Subject: [PATCH 1/2] Wildcard identifiers in constants --- text/0000-const-wildcard.md | 120 ++++++++++++++++++++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 text/0000-const-wildcard.md diff --git a/text/0000-const-wildcard.md b/text/0000-const-wildcard.md new file mode 100644 index 00000000000..35727c7fd43 --- /dev/null +++ b/text/0000-const-wildcard.md @@ -0,0 +1,120 @@ +- Feature Name: `const_wildcard` +- Start Date: 2018-08-18 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +# Summary +[summary]: #summary + +Allow assigning constants to `_`, as in `const _: TYPE = VALUE`, analogous to +`let _ = VALUE`. + +# Motivation +[motivation]: #motivation + +The ability to ensure that code type checks while discarding the result is +useful, especially in custom derives. For example, the following code will not +compile if the type `MyType` doesn't implement the trait `MyTrait`: + +```rust +const _FOO: () = { + use std::marker::PhantomData; + struct ImpelementsMyTrait(PhantomData); + let _ = ImplementsMyTrait::(PhantomData); // type checking error if MyType: !MyTrait + () +}; +``` + +Unfortunately, this requires coming up with a unique identifier to assign to. +This is error-prone because no matter what identifier is chosen, there's always +a possibility that a user will have already used the same identifier in their +code. If writing `const _: () = { ... }` were valid, then this would be a +non-issue - the `const _` could be repeated many times without conflicting with +any other identifier in scope. + +# Guide-level explanation +[guide-level-explanation]: #guide-level-explanation + +Allow assigning to `_` when defining a new constant. Just like `let _`, this +doesn't introduce any new bindings, but still evaluates the rvalue at compile +time like any other constant. + +# Reference-level explanation +[reference-level-explanation]: #reference-level-explanation + +The following changes are made to the language: + +## Grammar + +The grammar of `item_const` is changed from: + +```text +item_const : CONST ident ':' ty '=' expr ';' ; +``` + +to: + +```text +item_const : CONST (ident | UNDERSCORE) ':' ty '=' expr ';' ; +``` + +## Type checking + +When type checking an associated `const` item, the token `_` may not occur as +the name of the item. + +When type checking a `const` item not inside an `impl` item, the token `_` is +permitted as the name of such an item. When that token does occur, it is +replaced with a freshly generated and unique identifier. + +# Drawbacks +[drawbacks]: #drawbacks + +The rules around constant identifiers are made somewhat more complicated, as is +the compiler logic for handling them. A distinction is introduced between +associated `const` items (inside `impl`s) and non-associated `const` items. + +# Rationale and alternatives +[alternatives]: #alternatives + +## Rationale + +This would allow more ergonomic uses of a number of patterns used today: +- Ensuring that types have certain trait bounds in custom derives, as explained + in the [Motivation] section. +- [`const_assert!`](https://docs.rs/static_assertions/0.2.5/static_assertions/macro.const_assert.html) + and other macros in the + [`static_assertions`](https://docs.rs/static_assertions/0.2.5/static_assertions/index.html) + crate, which currently work only in a scope (so that they can use a `let` + binding) or requires the user to specify a scope-unique name for a function + which will be used to contain the expression that is the meat of the macro. + +Eventually, we will likely want to support fully general pattern matching just +like in `let` bindings (e.g., `const (a, b): (u8, u8) = (1, 1)`) to not have +`const _` be a special case in the language. However, this RFC leaves the +details of such a design up to a future RFC. + +## Alternatives + +- We could provide procedural macros with an API that fetches a new, + globally-unique identifier. +- We could support anonymous modules (`mod { ... }` or `mod _ { ... }`). +- We could support anonymous top-level functions (`fn _() { ... }`). + +# Prior art +[prior-art]: #prior-art + +Go allows unnamed constants using the syntax `const _ = ...`. It also allows +top-level variable bindings which are evaluated at init time, before `main` is +run - `var _ = ...`. This latter syntax is often used to ensure that a +particular type implements a particular interface, as in this example [from the +standard library](https://golang.org/src/math/big/ftoa.go#L379): + +```go +var _ fmt.Formatter = &floatZero // *Float must implement fmt.Formatter +``` + +# Unresolved questions +[unresolved]: #unresolved-questions + +None. From 1100a4edf1276103cf1daffbc465f8752735f584 Mon Sep 17 00:00:00 2001 From: Mazdak Farrokhzad Date: Mon, 8 Oct 2018 17:18:03 +0200 Subject: [PATCH 2/2] RFC 2526 --- text/{0000-const-wildcard.md => 2526-const-wildcard.md} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename text/{0000-const-wildcard.md => 2526-const-wildcard.md} (96%) diff --git a/text/0000-const-wildcard.md b/text/2526-const-wildcard.md similarity index 96% rename from text/0000-const-wildcard.md rename to text/2526-const-wildcard.md index 35727c7fd43..b4f0ae9d0c6 100644 --- a/text/0000-const-wildcard.md +++ b/text/2526-const-wildcard.md @@ -1,7 +1,7 @@ - Feature Name: `const_wildcard` - Start Date: 2018-08-18 -- RFC PR: (leave this empty) -- Rust Issue: (leave this empty) +- RFC PR: [rust-lang/rfcs#2526](https://github.com/rust-lang/rfcs/pull/2526) +- Rust Issue: [rust-lang/rust#54912](https://github.com/rust-lang/rust/issues/54912) # Summary [summary]: #summary