Rust

7312 readers

47 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 2 years ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

EdTheLegendary@programming.dev

kahnclusions@programming.dev

torcherist@programming.dev

things rust shipped without (2015) (graydon2.dreamwidth.org)

submitted 6 days ago by azdle@news.idlestate.org to c/rust@programming.dev

24 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] FizzyOrange@programming.dev 8 points 6 days ago (2 children)

One mistake they did unfortunately ship though is bind patterns that look like variable names.

[–] shape_warrior_t@programming.dev 12 points 5 days ago (2 children)

There was a recent langdev Stack Exchange question about this very topic. It's a bit trickier to design than it might seem at first.

Suppose we require a keyword -- say var -- before all binding patterns. This results in having to write things like
for (&(var x1, var y1, var z1), &(var x2, var y2, var z2)) in points.iter().tuple_windows() {},
which is quite a bit more verbose than the current
for (&(x1, y1, z1), &(x2, y2, z2)) in points.iter().tuple_windows() {}.
Not to mention you'll have to write let var x = 0; just to declare a variable, unless you redesign the language to allow you to just write var x = 0 (and if you do that, you'll also have to somehow support a coherent way to express if let Some(x) = arr.pop() {} and let Some(x) = arr.pop() else {todo!()}).

Suppose we require a keyword -- say const -- before all value-matching patterns that look like variables. Then, what's currently

match (left.next(), right.next()) {
    (Some(l), Some(r)) => {}
    (Some(l), None) => {}
    (None, Some(r)) => {}
    (None, None) => {}
}

turns into either the inconsistently ugly

match (left.next(), right.next()) {
    (Some(l), Some(r)) => {}
    (Some(l), const None) => {}
    (const None, Some(r)) => {}
    (const None, const None) => {}
}

or the even more verbose

match (left.next(), right.next()) {
    (const Some(l), const Some(r)) => {}
    (const Some(l), const None) => {}
    (const None, const Some(r)) => {}
    (const None, const None) => {}
}

and you always run the risk of forgetting a const and accidentally binding a new match-all variable named None -- the main footgun that syntactically distinguishing binding and value-matching patterns was meant to avoid in the first place.

Suppose we require a sigil such as $ before one type of pattern. Probably the best solution in my opinion, but that's one symbol that can no longer be used for other things in a pattern context. Also, if you're already using sigils before variable names for other purposes (I've been sketching out a language where a pointer variable $x can be auto-dereferenced by writing x), doubling up is really unpleasant.

...So I can understand why Rust chose to give the same, most concise possible syntax for both binding and value-matching patterns. At least compiler warnings (unused, non-snake-case variables) are there to provide some protection from accidentally turning one into the other.

[–] soc@programming.dev 4 points 4 days ago (1 children)

I went the "only let introduces bindings" route, and I'm pretty happy so far:

if (left.next(), right.next())
... is (Some(let l), Some(let r)) { /* use l and r */ }
... is (Some(let l), None       ) { /* use l       */ }
... is (None,        Some(let r)) { /* use r       */ }
... is (None,        None       ) { /* use nothing */ }
}

[–] sugar_in_your_tea@sh.itjust.works 1 points 2 days ago

Yeah, they could literally have the same syntax as now, but w/ let when introducing a variable. So:

match (left.next(), right.next()) {
    (Some(let l), Some(let r)) => {}
    (Some(let l), None) => {}
    (None, Some(let l)) => {}
    (None, None) => {}
}

Or you could put the let before the Some(...) as let Some(l), which allows us to keep the current if let Some(...) = ... syntax. Either of those would feel more consistent than the current implementation.

[–] TehPers@beehaw.org 2 points 4 days ago

I completely forgot that unit structs/variants define their own associated consts. I wonder if in patterns the type can be used instead of the associated const though? That might resolve a lot of the headache. It'd mean changing the way the ident is resolved to looking in the type namespace though.

const <block> already works as a pattern I believe? That could be used instead for constants.

Literals would always work in-place as constant expressions.

[–] TehPers@beehaw.org 6 points 5 days ago

As in using consts (or variables you think are consts) as refutable patterns? Yeah this was an oversight I'm sure.

One option is an edition change requiring a const keyword, so

match foo {
    const BAR => {},
    baz => {},
}

Right now they use a lint to try to warn the dev though.