this post was submitted on 25 Apr 2024
42 points (100.0% liked)

Rust

5980 readers
105 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
snowe@programming.dev
Ategon@programming.dev
EdTheLegendary@programming.dev
kahnclusions@programming.dev
torcherist@programming.dev
42
Inline const expressions have been stabilised (github.com)
submitted 6 months ago by SorteKanin@feddit.dk to c/rust@programming.dev
12 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] kevincox@lemmy.ml 6 points 6 months ago (2 children)

This is a nice small feature. I'm curious about the commit description:

foo(const { 1 + 1 })

which is roughly desugared into

struct Foo;
impl Foo {
    const FOO: i32 = 1 + 1;
}
foo(Foo::FOO)

I would have expected it to desugar to something like:

foo({
  const TMP: i32 = 1 + 1;
  TMP
})

But I can't seem an explanation why the struct with impl is used. I wonder if it has something to do with propagating generics.

[–] 0v0@sopuli.xyz 10 points 6 months ago (1 children)

It's because it has to work in pattern contexts as well, which are not expressions.

[–] SorteKanin@feddit.dk 2 points 6 months ago (1 children)

Wait, in pattern context? How? Can you give an example?

[–] 0v0@sopuli.xyz 10 points 6 months ago 
fn foo(x: i32) {
    match x {
        const { 3.pow(3) } => println!("three cubed"),
        _ => {}
    }
}

But it looks like inline_const_pat is still unstable, only inline_const in expression position is now stabilized.

[–] Giooschi@lemmy.world 7 points 6 months ago

They tested the same strings on that implementation

The code they were looking at was used for writing the table, but they were testing the one that read it (which is instead correct).

though judging by the recent comments someone’s found something.

Yeah that's me :)The translation using an associated const also works when the const block uses generic parameters. For example:

fn require_zst<T>() {
    const { assert!(std::mem::size_of::<T>() == 0) }
}

This can be written as:

fn require_zst<T>() {
    struct Foo<T>(PhantomData<T>);
    impl<T> Foo<T> {
        const FOO: () = assert!(std::mem::size_of::<T>() == 0);
    }
    Foo::<T>::FOO
}

However it cannot be written as:

fn require_zst<T>() {
    const FOO: () = assert!(std::mem::size_of::<T>() == 0);
    FOO
}

Because const FOO: () is an item, thus it is only lexically scoped (i.e. visible) inside require_zst, but does not inherit its generics (thus it cannot use T).