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.

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 preferring the PartialEq/PartialOrd behavior, but that's way more niche than just treating 0 and -0 as equal and NaN as always unequal.

Drop ::

Agreed.

Drop as

Disagree. I prefer changing it to only do type conversions (i.e. f32 -> f64 is valid, but f64 -> f32 isn't). Value conversions should use a different syntax.

Drop if-let

Disagree. Either keep as-is, or put let next to the new symbol (if Some(let i) = ...). I don't like chaining, if you want that, just introduce a block or something. It's a bit more verbose, but it's way less confusing.

Other languages have destructuring, and this is basically the same thing, and should be handled similarly. For example, in javascript: let {some: myVar} = option_object; (i.e. object that looks like {some: value}. An option is basically just an object w/ two members, so the syntax should be similar: let Some(my_var) = option_object else default_value;. Throwing an if in front should merely do something like Python's walrus operator, if my_var := some_call(), which evaluates whether the expression is truthy, but in the Rust case, it would evaluate whether the assignment was able to be made.

I think if-let makes sense, but don't expand it.

Drop procedure syntax

Why? What value does -> () provide? Why not elide that?

Rectify “almost rules” into “always rules”

This sounds pretty pedantic. Most of those are quite intuitive, and a lot of this is redundant given the rest of your post.

Remove significance of semicola

Disagree. I like that semicolons have meaning in Rust, because in most languages they just feel unnecessary, and languages w/o them feel awkward since you're generally limited to one statement per line.

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.

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