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

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

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.

Drop struct initialization syntax

…

Named parameters using =

I would like to take this a step further: support default arguments (fn func(a: int = 0); func(); func(a=0)), and then have struct initialization work like that. It’s really nice in Python, though I’d like some rules to require args w/ default values to use the assignment syntax, and _require args w/o default values to be in positional order (our codebase is littered with long_func_name(long_var_name=long_var_name, …) where function calls are incredibly long and redundant). That does a few things for us:

• make defaults more obvious - no more T::new() since now you can just do T() if you just want defaults
• make special cases obvious - func(1, 2, some_arg=value) makes it obvious that value is special
• eliminates the T{…} syntax, since you can just use the T(…) syntax

We probably disagree about requiring positional args to use the assignment syntax, but both your preference and mine can be enforced w/ conventions (i.e. give your variables relevant names to the function).

Replace impl and eliminate the impl X for Y syntax

I disagree, though I can see where you’re coming from. Many OOP languages use the first option, and the second try to reuse keywords.

But you’re also missing one use of the impl keyword: fn func() -> impl Trait.

I come from Go and I honestly like the syntax there:

func (T self) fn_name(args...) {
}

Many don’t. I like it because it shows that these methods aren’t part of the type T, they’re “attached” to it. That’s much closer to how this actually works that how Java represents it. It’s a small thing, but for something low-level like Rust, I think that makes sense.

Also, it makes room for implementing additional functionality on existing types outside of that package. This doesn’t work exactly as I’d prefer, but the syntax opens the door to that.

Stop using macros to emulate varargs

I’m on the fence about this. The println!(“{}”, val) syntax is really nice, and that’s one of the common uses for varargs. If your varargs are all the same type, you can use slices: fn func(varargs: &[T]); func(&[1, 2, 3]) and avoid macros entirely. If your types are inconsistent (i.e. C’s varargs), you’re going to have a rough time w/ any vararg syntax and will need a macro anyway.

I agree that macros shouldn’t be abused to emulate varargs, but I don’t think we actually need a vararg syntax and can use existing tools.

Drop range syntax

Agree. Use a built-in like Python’s range(…) instead of fancy syntax, and have the type ([T], &[T], or vec<T>) be inferred at compile time. This can probably just drop-in to everywhere the range syntax is being used currently. It’s a little more verbose, but it’s way clearer.

Drop array and slice syntax

Are you suggesting using keywords/methods instead? So [T].slice(…) or even Array<T>.slice(…)? I think that’s reasonable, and it can work similarly to Vec, but it would complicate the syntax a bit for my vararg proposal. But yeah, [T, count] is pretty ugly, but I’m not convinced Array<T, count> is all that much better.

I think your post could benefit from a couple examples.

Make generics use [] instead of <>/::<>

I prefer D’s ! approach: T!U or T!(U). I would switch macros to T#(…) instead, since # is already used for things adjacent to macros anyway. But to minimize impact, we could just use # for generics instead.

I’m not a fan of the [] for generics, and I disagree w/ Go using that. <> is awkward due to conflicts with comparison operators, so I agree that it needs to go.

Fold Index and IndexMut into Fn trait family

Eh, I’m less interested in this one, but I don’t have a strong opinion. Calling *T.index(…) isn’t a big ask…

Remove the hierarchy between Eq/Ord and PartialEq/PartialOrd traits

This is certainly annoying, but surely the right solution is to just make floats implement Eq/Ord, no? I can understand someone prefe

func1()->A{...}
func2()->A{...}

let mut thing = func1();
thing = func2();

Drop if-let

Over my cold dead body. if-let-else is such a fantastic pattern. Makes everything an order of magnitude more readable. Works so nicely for unwrapping opts/errs.

if foo is Some(foo) {
    // ...
}

let Some(foo) = foo else {
    todo!();
};

let i = if let Some(i) = opt_number {
    i
} else {
    return 0;
};