Don’t 99% of people don’t need the efficiency boost of not having a garbage collector. Instead learn a Functional Programming Language like Scala, OCaml or F#

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.

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()) {
    (

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 */ }
}

Interesting perspective. Not sure I agree with most of the suggestions though.

Some of the earlier ones remind me of C#'s records. Were they inspired from them?

Some of the later ones just feel like Go to me.

I like the idea of dropping syntax for ranges. It does feel like the syntax just leads to confusion.

Named parameters are problematic because of parameter names becoming significant to the API. See Python’s * and / in parameter lists (like def foo(a, *, b) for example).

I’m curious, have you used Rust much? Most of those changes just feel like “rust should be more familiar to me” changes.

Also:

As Rust 2.0 is not going to happen, Rust users will never get these language design fixes

Isn’t necessarily true for most of your suggestions. Since most of them are just changes to syntax semantics and not language semantics they could be made in an edition.

The “drop the array and slice syntax” is just nuts. With 0 justification.