profile
viewpoint
scottmcm Pacific Northwest, USA This is a personal account. My actions and opinions are my own, and are not taken on behalf of my employer.

scottmcm/rev_slice 3

A simple alternative to negative indexing on rust slices

scottmcm/pawn-rs 1

An unchecked borrow-like operation for Cells.

scottmcm/rust 1

A safe, concurrent, practical language.

scottmcm/compiler-builtins 0

Porting `compiler-rt` intrinsics to Rust

scottmcm/edition-guide 0

A guide to changes between various editions of Rust

scottmcm/jpeg-decoder 0

JPEG decoder written in Rust

scottmcm/miri 0

An interpreter for Rust's mid-level intermediate representation

scottmcm/multipart 0

A backend-agnostic extension for file uploads in HTTP libraries for Rust

pull request commentrust-lang/rust

Format Duration microseconds with "us" suffix, without Unicode

I'm torn here. What you say isn't unreasonable, but I'm also always opposed to using SI incorrectly, and it's unambiguously the case that "µs" is correct under SI and "us" isn't.

I think I might be more persuaded for Display, but since Debug is developer-focused I think it's fine for them to be expected to configure their system to allow Unicode, since even Windows terminals can do that fine these days.

joshtriplett

comment created time in an hour

issue commentrust-lang/rfcs

Trait objects for multiple traits

@jgarvin Good comment! Makes me think that, rather than Send and Sync being special, perhaps they should just be ordinary #[marker] traits, and all #[marker] traits should get the "can be added to other traits in dyn" behaviour.

sgrif

comment created time in 16 hours

issue commentrust-lang/rust

Tracking issue for Range[Inclusive]::is_empty (feature range_is_empty)

To anyone following this tracking issue, I've made a PR to request stabilization of these methods: #75132

scottmcm

comment created time in 16 hours

pull request commentrust-lang/rust

Stabilize Range[Inclusive]::is_empty

Since this needs an FCP, picking someone from libs who recently re-tagged the tracking issue:

r? @KodrAus

scottmcm

comment created time in 16 hours

PR opened rust-lang/rust

Stabilize Range[Inclusive]::is_empty needs-fcp

I would like to propose these two simple methods for stabilization:

  • Knowing that a range is exhausted isn't otherwise trivial
  • Clippy would like to suggest them, but had to do extra work to disable that path https://github.com/rust-lang/rust-clippy/issues/3807 because they're unstable
  • These work on PartialOrd, consistently with the stable contains method, and are thus more general than iterator-based approaches that need Step
  • They've been unchanged for some time, and have picked up uses in the compiler
  • Stabilizing them doesn't block any future iterator-based is_empty plans, as these inherent ones are preferred in name resolution

https://doc.rust-lang.org/nightly/std/ops/struct.Range.html#method.is_empty https://doc.rust-lang.org/nightly/std/ops/struct.RangeInclusive.html#method.is_empty

Closes #48111

+2 -17

0 comment

6 changed files

pr created time in 17 hours

create barnchscottmcm/rust

branch : stabilize-range-is-empty

created branch time in 17 hours

push eventscottmcm/rust

bors

commit sha bb67423577de689256483881ee9a8a0df34f7cd7

Auto merge of #5804 - flip1995:backport_remerge, r=flip1995 Backport remerge rust-1.44.1 r? @ghost changelog: none

view details

Stein Somers

commit sha ca253cab3689c0d525dabda10e35c469839b2c4b

Clean up or comment every unwrap in BTreeMap's main code.

view details

Stein Somers

commit sha b82d332c52dde1680b21c0281f08cc5f30edc082

Separate off BTreeMap support functions and loose their irrelevant bounds

view details

flip1995

commit sha ef896faa0153d0d96b6d6eafe7dd53b178525a25

Fix deploy script for beta deployment Since the beta/ directory already exists, we can't copy the complete master dir

view details

flip1995

commit sha c65eb4d66314d22d85cf2e58ff20ec1ca7404751

Track tag files, before checking for the diff

view details

Joshua Nelson

commit sha 631b2b9b722a3333aa5931fbbfa9df8846d48380

Remove unused lazy_static

view details

Lokathor

commit sha 48ec236c8c7c5a32077c465eb254646a9860f802

start GBA file.

view details

bors

commit sha 6ee1b62c811a6eb68d6db6dfb91f66a49956749b

Auto merge of #72481 - marmeladema:duration-consts-2, r=oli-obk Constify most non-trait `Duration` methods as described in #72440 The remaining methods could probably be made const once https://github.com/rust-lang/rust/pull/72449 lands with support for `f<32|64>::is_finite()`.

view details

flip1995

commit sha cf383cf48aa1bc09c50ae7d3599254c82b7dc0bf

Update changelog to beta-1.46

view details

flip1995

commit sha aba0d244d419261f94b3d942953412e35c3e857e

Typo: Change Log -> Changelog

view details

Guillaume Gomez

commit sha aabca44d27fbede156d2f87ee75f24fc3176d052

Enforce even more the code blocks attributes check through rustdoc

view details

Guillaume Gomez

commit sha d70e6e10c50998ea7ffa1e0e11aa5129b7468405

Apply review comments

view details

Guillaume Gomez

commit sha 3dc8544e7bb26e3ee791b5c9b4c4e3da7ad9508a

Update code to new invalid_codeblock_attributes lint name

view details

bjorn3

commit sha 4497b9ad02fc0e7d8f5e653e2acf7ccc3266b2f2

Remove leftover from emscripten fastcomp support This is no longer used since #63649

view details

Linda_pp

commit sha e28c0ea2be3407279ffb1768aa747e9ba8a4fbb6

Fix typo in the latest release note

view details

Guillaume Gomez

commit sha 03bbe9d2c93623f789758df67b86f6ce4154951a

Clean up E0723 explanation

view details

Guillaume Gomez

commit sha 52c65e05f53e7a49345bc3041e5656735fdc4f9c

Remove elements iterator clone and only keep first element instead

view details

Manish Goregaokar

commit sha 98450757e5fa18ee0be9213d2830c9363b0f5fd3

Revert "Remove "important traits" feature" This reverts commit 1244ced9580b942926afc06815e0691cf3f4a846.

view details

Manish Goregaokar

commit sha 3cecd6003b3eb15168421084a27223596517899c

Revert "Remove spotlight usage" This reverts commit 13c6d5819aae3c0de6a90e7f17ea967bf4487cbb.

view details

Manish Goregaokar

commit sha c90fb7185a5febb00b7f8ccb49abceacd41bad6e

Move spotlight next to the return type

view details

push time in 18 hours

startedKixiron/rust-langdev

started time in 21 hours

issue commentrust-lang/lang-team

Portable SIMD project group

The "language design" portion of it is basically limited to "should we add intrinsic capabilities and therefore tie ourselves to LLVM even further", correct?

I don't think that, from a formal specification perspective, this is true. Another rust implementation could provide a fully semantically-correct implementation by just calling the scalar versions of all the functions in the appropriate loops.

Now, obviously from a quality-of-implementation perspective a compiler would likely want to provide something smarter than that, to take better advantage of hardware capabilities. But I think LLVM is only one way of getting that -- albeit what I would probably pick if I was implementing atop of it anyway. We could also have it with an implementation strategy of cfg_if!s to call existing-stable intrinsics on the relevant platforms, for example, as people hit them or they stabilize.

My expectation from "portable" is that such differences would necessarily be inobservable semantically, and thus I think I personally would be fine with this being entirely a libs projects, to figure out the portable set of operations, how best to expose a rust interface to those, and how best to have them interop with non-portable platform intrinsics where needed. (There might be some libs-impl/compiler/lang conversations about implementations details, but I suspect none of those will lock us into things.)

hsivonen

comment created time in a day

issue commentrust-lang/rust

MIR InstCombine introduces copies of mutable borrows

This is now also fixed by https://github.com/rust-lang/rust/pull/72820, which removed this fold in InstCombine

scottmcm

comment created time in a day

pull request commentrust-lang/rust

Use u32::from_le_bytes to fix a FIXME

Hmm, this is basically the inverse of to_octets, right? That method is

    pub fn octets(&self) -> [u8; 4] {
        // This returns the order we want because s_addr is stored in big-endian.
        self.inner.s_addr.to_ne_bytes()
    }

So it seem like the right implementation here might just be

    pub const fn new(a: u8, b: u8, c: u8, d: u8) -> Ipv4Addr {
        // s_addr is stored in big-endian on all machines, so the array is provided in big-endian and
        // the native endian conversion method is used so that it's never swapped.
        Ipv4Addr { inner: c::in_addr { s_addr: u32::from_ne_bytes([a, b, c, d]) } }
    }
lzutao

comment created time in a day

Pull request review commentrust-lang/rust

Use u32::from_le_bytes to fix a FIXME

 impl Ipv4Addr {     #[stable(feature = "rust1", since = "1.0.0")]     #[rustc_const_stable(feature = "const_ipv4", since = "1.32.0")]     pub const fn new(a: u8, b: u8, c: u8, d: u8) -> Ipv4Addr {-        // FIXME: should just be u32::from_be_bytes([a, b, c, d]),-        // once that method is no longer rustc_const_unstable-        Ipv4Addr {-            inner: c::in_addr {-                s_addr: u32::to_be(-                    ((a as u32) << 24) | ((b as u32) << 16) | ((c as u32) << 8) | (d as u32),-                ),-            },-        }+        Ipv4Addr { inner: c::in_addr { s_addr: u32::from_be_bytes([a, b, c, d]) } }

Very likely that I was wrong in the TODO -- I think I was wrong in https://github.com/rust-lang/rust/pull/57740#discussion_r249326435 too

lzutao

comment created time in a day

pull request commentrust-lang/rust

Implement `Index` and `IndexMut` for arrays

Note that, when LLVM knows the index is in-bounds, it already removes the bounds check, even when indirected through a slice. Demo: https://rust.godbolt.org/z/hWYG58

pubfnbar

comment created time in 3 days

issue openedrust-lang/lang-team

MCP: per-edition preludes

Proposal

Summary and problem statement

To give libs more flexibility, we should allow different preludes per edition.

Motivation, use-cases, and solution sketches

Due to nuances of trait resolution, adding a trait to the prelude is a (technically allowed) breaking change. To help avoid heavy impact, however, it would be nice to be able to make those changes opt-in. The edition mechanism seems like a reasonable place to do this: it means that new code (using cargo new, which defaults to the new edition) will get the new traits in its prelude, but old code using traits that conflict won't be immediately broken.

The basic change here is easy: instead of putting use std::prelude::v1::*; in every module, put use std::prelude::v2018::*; (or analogously for other editions). Giving warnings and

Out of scope

I would like to leave what, if anything, would change in such a prelude out of scope from this conversation. We can start with all of them being the same as the (could then be deprecated) v1 module. And lang and/or libs can then consider individual changes in a future edition (or existing ones) as separate changes.

Prioritization

This fits decently under "Targeted ergonomic wins and extensions". Having TryInto available in the prelude, for example, would help the compiler give error messages on conversions mentioning that without the confusion of the suggestion not working until an additional trait is used.

Links and related work

https://github.com/rust-lang/rust/issues/65512

Initial people involved

@scottmcm

What happens now?

This issue is part of the experimental MCP process described in RFC 2936. Once this issue is filed, a Zulip topic will be opened for discussion, and the lang-team will review open MCPs in its weekly triage meetings. You should receive feedback within a week or two.

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

created time in 4 days

pull request commentrust-lang/rust

Implement `Index` and `IndexMut` for arrays

You have some PR errors:

error: implementation has missing stability attribute
   --> library/core/src/array/mod.rs:201:1
    |
201 | / impl<T, I, const N: usize> Index<I> for [T; N]
202 | | where
203 | |     I: SliceIndex<[T]>,
204 | | {
...   |
212 | |     }
213 | | }
    | |_^

error: implementation has missing stability attribute
   --> library/core/src/array/mod.rs:215:1
    |
215 | / impl<T, I, const N: usize> IndexMut<I> for [T; N]

You'll need to add something like this to them:

#[stable(feature = "index_trait_on_arrays", since = "1.47")]

(Trait impls are insta-stable, hence the needs-fcp label and the attribute not being unstable, and 1.47 is the current nightly)

pubfnbar

comment created time in 4 days

pull request commentrust-lang/rust

add `slice::array_chunks` to std

Looks like this accidentally added a submodule? image

lcnr

comment created time in 5 days

pull request commentrust-lang/rfcs

RFC: Elide array size

An observation here: this feels like the value-space version of what impl Trait does in the type-space.

To flesh that out:

  • It's long been the Rust rule that items have their types fully specified. I think just changing this one specific bit isn't the right holistic change. As a trivial example, why would it be allowed in const FOO but not const fn foo()?
  • Looking at the goal here, it seems to be that the crate doesn't want to promise a specific size from a semver perspective -- if it did it could just put that one by copying it from the error -- but at the same time allow the compiler to know what the concrete value there is when compiling things. That sounds very much to me like the same thing we had with types, where we wanted to add a way for people to promise that they're returning some iterator of u32s, but not its concrete type. To push that a bit further, the proposed example of static BLORP_NUMBERS: [u32; _] = [0, 8, 15]; can be roughly thought of as being static BLORP_NUMBERS: impl Copy + AsRef<[u32]> = [0, 8, 15];: you can copy it and a contiguous (thus indexable) thing, but you can't actually see its length at compile time, only at runtime.
  • So to me, rather than this proposal having the size be inferred -- which would make changing the size a breaking change because one could assign it to something of non-inferred size -- this should have additional semantic rules. So then the example would mean something like static BLORP_NUMBERS: [u32; impl usize] = [0, 8, 15];: we promise there's some usize there, but you can't take a dependency on which one is there. (That syntax being a placeholder, of course, just there to ape impl Trait.)

(Note that I'm only talking about static and const here -- having something like this for let seems clearly good, and if I remember the discussions about things correctly I think it's going to happen as part of const generics.)

llogiq

comment created time in 15 days

pull request commentrust-lang/rust

Impl Default for ranges

Since Vec defaults to an empty Vec, isn't it only logical that Range would default to en empty Range?

Let say it is: then wouldn't it also be "only logical" that the other kinds of RangeBounds would also default to an empty range? Which of course can't happen: It's straight impossible for RangeFull, RangeFrom, RangeTo, and RangeToInclusive. And doing it for RangeInclusive either means a new trait (because Default::default()..=Default::default() is typically non-empty) or forcing forever the "there's an extra flag to ignore the fields" implementation of RangeInclusive.

And the other kind of RangeBounds in std is (Bound, Bound), but @c410-f3r just argued earlier that Bound shouldn't be Default, which means that that pair can't be Default either.

For instance, it allows resize on a Vec. Default is needed even if the vector is only ever shrunk in practice.

resize doesn't use Default; nor does resize_with. resize_default does, obviously, but that's currently deprecated. Not to mention that there's always just truncate for shrinking...

c410-f3r

comment created time in 16 days

issue commentrust-lang/rust

Breaking change/regression in nightly? Hash of `Discriminant` now produces different results across CPU architectures

I see lang was pinged here, but it's not clear to me that this is a lang issue. AFAIK Discriminant<> and Hash are libs's domain.

(Personally it seems like there's no guarantee that Hash does the same thing on different platforms, so I'd be inclined to solve this by just putting a note in the docs that Hashes across different builds can be different. I do like the point that it seems weird to a discriminant to be a [ui]size type instead of a [ui]N type, though.)

korken89

comment created time in 20 days

pull request commentrust-lang/rust

Remove trait LengthAtMost32

@kpp I'd say no. Leave this one as just removing the bound. No need to mix a new non-trivial implementation into this simple PR.

kpp

comment created time in 21 days

pull request commentrust-lang/rust

stabilize ptr_offset_from

Also nominating the lang team because this exposes an intrinsic.

This used to just be implemented with normal code, IIRC. Is there some observable semantics that the intrinsic provides? Or is it just for optimization/miri convenience?

RalfJung

comment created time in 24 days

pull request commentrust-lang/rust

Only allow `repr(i128/u128)` on enum

This seems like it's closing an obvious gap, so personally I'm happy to see it happen without an FCP.

nbdd0121

comment created time in a month

pull request commentrust-lang/rust

Impl Default for ranges

The fact that 0..0 and 0..=0 are so different makes me somewhat skeptical here. Even in the domain example, it doesn't seem obvious that the Range<T>: Default would be useful -- defaulting to an empty domain (0..0) doesn't seem like what would be wanted, nor would defaulting to a singleton domain (0..=0).

I'll note that, for example, std::ops::Bound doesn't impl Default either.

c410-f3r

comment created time in a month

pull request commentrust-lang/rust

Make `likely` and `unlikely` const, gated by feature `const_unlikely`

I agree that unstable things generally don't need a lang FCP, especially for intrinsics that are by nature internal and more about compiler/libs-impl concerns than about the conceptual language itself.

nbdd0121

comment created time in a month

pull request commentrust-lang/rust

deprecate wrapping_offset_from

Thanks for the ping here, @oli-obk. My recollection is that that musing was from way back when the only method was the safe one (https://doc.rust-lang.org/1.22.0/std/primitive.pointer.html#method.offset_to), and I thought that there should probably be an unsafe one. I have no attachment to the safe one, and am fine with its removal.

RalfJung

comment created time in a month

pull request commentrust-itertools/itertools

add try_iterate: iterate function until it returns None

Given that unfold already exists, it's not clear to me that this is worth having.

yihuang

comment created time in a month

issue commentrust-lang/rust

make `pub type foo = bar` and `pub use bar as foo` interchangable in next edition

It it possible there's anyone relying on this for the opposite, exporting a type while intentionally not exporting the constructor? I guess it doesn't hide PubType { 0: 5 }, though...

yaahc

comment created time in 2 months

issue commentrust-lang/rfcs

Allow `_ @ CONST` in match arms

I raised the const { CONST } version on IRLO about two months back: https://internals.rust-lang.org/t/bring-enum-variants-in-scope-for-patterns/12104/51?u=scottmcm

There are two interesting replies that suggest the extra noise from requiring the keyword in the pattern would be too annoying for the value.

We're very good at emitting at least one warning in the mistaken cases here; is there maybe a subset that we could upgrade to be deny-by-default because it's so unlikely to be correct?

mahkoh

comment created time in 2 months

pull request commentrust-itertools/itertools

Added Range iterator

I feel pretty strongly that it shouldn't be drain because the important part to me about drain is that it modifies the receiver even if the return value is not used. I feel like this is far more like Vec::get.

TrolledWoods

comment created time in 2 months

pull request commentrust-lang/rfcs

Inline `const` expressions and patterns

Discussion has settled and the RFC has been updated, so I think it's time for more lang eyes here.

@rfcbot fcp merge

My mini-summary: this adds const { ... } as a way to require that the enclosed code is run at compile-time (like happens in things like array lengths), but without requiring naming an item or annotating types explicitly (which is useful for the same reasons that async { ... } and closures are useful). It also opens the possibility of simplifying promotion rules in the future.

ecstatic-morse

comment created time in 2 months

pull request commentrust-lang/rust

add raw_ref macros

@rfcbot reviewed

Definitely no concerns with this as unstable.

RalfJung

comment created time in 2 months

issue commentCitiesSkylinesMods/TMPE

Automatically lower speed limits on roundabouts [Suggestion]

Thanks, folks! I'm excited to try this when 11.6 comes out!

scottmcm

comment created time in 2 months

pull request commentrust-lang/rfcs

Inline `const` expressions and patterns

@pickfire Same reason we don't have unsafe match. See https://github.com/rust-lang/rfcs/pull/2920#issuecomment-623783875 above.

ecstatic-morse

comment created time in 3 months

pull request commentrust-lang/rfcs

Inline `const` expressions and patterns

@CryZe right now const is an item, so it follows item rules, and there's many more consequences of that than just type inference. I prefer adding the expression form -- especially because we have it for other kinds of blocks -- to either making the results less consistent or trying to change all items.

item, specifies type expression, inferred type
fn foo() -> i32 { 4 } ││ { 4 }
async fn foo() -> i32 { 4 } async { 4 }
const fn foo() -> i32 { 4 } const { 4 }

Or, if you imagine it's inside a fn bar<T>(),

item, ERROR cannot reference external type parameter expression, OK can use the type parameter
fn foo() -> usize { mem::size_of::<T>() } ││ { mem::size_of::<T>() }
async fn foo() -> usize { mem::size_of::<T>() } async { mem::size_of::<T>() }
const fn foo() -> usize { mem::size_of::<T>() } const { mem::size_of::<T>() }
ecstatic-morse

comment created time in 3 months

Pull request review commentrust-lang/rfcs

Inline `const` expressions and patterns

+- Feature Name: `inline_const`+- Start Date: 2020-04-30+- RFC PR: [rust-lang/rfcs#2920](https://github.com/rust-lang/rfcs/pull/2920)+- Rust Issue: TBD++# Summary+[summary]: #summary++Adds a new syntactical element called an "inline `const`", written as+`const { ... }`, which instructs the compiler to execute the contents of the+block at compile-time. An inline `const` can be used as an expression or+anywhere in a pattern where a named `const` would be allowed.++```rust+use std::net::Ipv6Addr;++fn mock_ip(use_localhost: bool) -> &'static Ipv6Addr {+    if use_localhost {+        &Ipv6Addr::LOCALHOST+    } else {+        const { &Ipv6Addr::new(0x2001, 0xdb8, 0, 0, 0, 0, 0, 0) }+    }+}++fn main() {+    match *x {+        0 ..= const { u32::MAX / 2 } => println!("low"),+        const { u32::MAX / 2 + 1 } ..= u32::MAX => println!("high"),+    }+}+```++# Motivation+[motivation]: #motivation++Rust has `const` items, which are guaranteed to be initialized at compile-time.+Because of this, they can do things that normal variables cannot.  For example,+a reference in a `const` initializer has the `'static` lifetime, and a `const`+can be used as an array initializer even if the type of the array is not+`Copy` (with [RFC 2203]).++[RFC 2203]: https://github.com/rust-lang/rfcs/pull/2203++```rust+fn foo(x: &i32) -> &i32 {+    const ZERO: &'static i32 = &0;+    if *x < 0 { ZERO } else { x }+}+++fn foo() -> &u32 {+    const RANGE: Range<i32> = 0..5; // `Range` is not `Copy`+    let three_ranges = [RANGE; 3];+}+```++Writing out a `const` declaration everytime we need a long-lived reference or+a non-`Copy` array initializer can be annoying. To improve the situation,+[RFC 1414] introduced rvalue static promotion to extend lifetimes, and+[RFC 2203] extended the concept of promotion to array initializers.+As a result, the previous example can be written more concisely.++[RFC 1414]: https://github.com/rust-lang/rfcs/pull/2203++```rust+fn foo(x: &i32) -> &i32 {+    if *x < 0 { &0 } else { x }+}++fn foo() -> &u32 {+    let three_ranges = [0..5; 3];+}+```++However, the fact that we are executing the array initializer or expression+after the `&` at compile-time is not obvious to the user. To avoid violating+their assumptions, we are very careful to promote only in cases where the user+cannot possibly tell that their code is not executing at runtime. This means a+[long list of rules][prom-rules] for determining the promotability of expressions, and it+means expressions that call a `const fn` or that result in a type with a `Drop`+impl need to use a named `const` declaration.++[prom-rules]: https://github.com/rust-lang/const-eval/blob/master/promotion.md#promotability++# Guide-level explanation+[guide-level-explanation]: #guide-level-explanation++This proposal is a middle ground, which is less verbose than named constants but+more obvious and expressive than promotion.++```rust+fn foo(x: &i32) -> &i32 {+  if *x < 0 { const { &4i32.pow(4) } } else { x }+}++fn foo() -> &u32 {+    let three_ranges = [const { (0..=5).into_inner() }; 3];+}+```++With this extension to the language, users can ensure that their code executes+at compile-time without needing to declare a separate `const` item that is only+used once.++## Patterns++Patterns are another context that require a named `const` when using complex+expressions.  Unlike in the expression context, where promotion is sometimes+applicable, there is no other choice here.++```rust+fn foo(x: i32) {+    const CUBE: i32 = 3.pow(3);+    match x {+        CUBE => println!("three cubed"),+        _ => {}+    }+}+```++If that `const` is only used inside a single pattern, writing the code using an+inline `const` block makes it easier to scan.++```rust+fn foo(x: i32) {+    match x {+        const { 3.pow(3) } => println!("three cubed"),+        _ => {}+    }+}+```++# Reference-level explanation+[reference-level-explanation]: #reference-level-explanation++This RFC extends the [grammar for expressions] to be,++[grammar for expressions]: https://doc.rust-lang.org/stable/reference/expressions.html#expressions++> ```+> ExpressionWithBlock :+>    OuterAttribute*†+>    (+>         BlockExpression+>       | AsyncBlockExpression+>       | UnsafeBlockExpression+>       | ConstBlockExpression // new+>       | LoopExpression+>       | IfExpression+>       | IfLetExpression+>       | MatchExpression+>    )+>+> ConstBlockExpression: `const` BlockExpression // new+> ```++This RFC extends the [grammar for patterns] to be,++[grammar for patterns]: https://doc.rust-lang.org/stable/reference/patterns.html++> ```+> Pattern :+>      LiteralPattern+>    | IdentifierPattern+>    | WildcardPattern+>    | RangePattern+>    | ReferencePattern+>    | StructPattern+>    | TupleStructPattern+>    | TuplePattern+>    | GroupedPattern+>    | SlicePattern+>    | PathPattern+>    | MacroInvocation+>    | ConstBlockExpression // new+>+> RangePatternBound :+>      CHAR_LITERAL+>    | BYTE_LITERAL+>    | -? INTEGER_LITERAL+>    | -? FLOAT_LITERAL+>    | PathInExpression+>    | QualifiedPathInExpression+>    | ConstBlockExpression // new+> ```++In both the expression and pattern context, an inline `const` behaves exactly+as if the user had declared a uniquely identified `const` with the block's+contents as its initializer. For example, in expression context, writing+`const { ... }` is equivalent to writing:

Are there any implementation concerns with accessing generic parameters? I understand that that rules for items prevent it, but it would seem very odd for expressions to be unable to access generic parameters -- by analogy, you can reference generic parameters in an async{} even though you cannot reference them in a nested async fn.

I think this analogy would be reasonable in a guide-level intuition argument, but shouldn't be how it's actually defined.

ecstatic-morse

comment created time in 3 months

pull request commentrust-lang/rfcs

Inline `const` expressions and patterns

braceless variant like const 5

I feel somewhat strongly that for this RFC, const{} should just ape unsafe{} syntactically.

We can talk about const foo() and unsafe *pointer at another time.

ecstatic-morse

comment created time in 3 months

pull request commentrust-lang/rfcs

Inline `const` expressions and patterns

Thanks for writing this up, @ecstatic-morse! The const-eval group's excellent promotion rules document you linked made me want this even more than I originally thought, as having a visible way to opt-in (and thus not need to worry about whether it is, isn't, or should be happening) seems so much better than trying to extend something that's already quite complicated.

ecstatic-morse

comment created time in 3 months

more