Removing let-else is the whole point of the linked article series:

Being able to do to everything Rust does, but without Rust’s zoo of if-then-else, match, if-let, let-else etc.

Thanks for your reply, some replies below!

requiring positional args to use the assignment syntax

Not sure, maybe my wording isn’t clear enough. What I intended to say is that arguments can be named, not that they have to. In any case, the order of arguments must match the order of parameters, named or not.

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

That removal could actually happen, so I didn’t list it. (Rust started requiring dyn and disallowed naked trait returns with edition 2018. So dropping the impl in that position might not be completely impossible like the other uses of impl.)

Are you suggesting using keywords/methods [for array and slice syntax] instead?

Yes, just methods.

I can understand someone preferring the PartialEq/PartialOrd behavior

You can have both – that’s what’s being made possible by them not being in a hierarchy.

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

It’s a bit late for that, isn’t it? ;-)

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

What value is provided by keeping it? Why a syntactic special-case for exactly that type and not any other random type?

languages w/o them feel awkward since you’re generally limited to one statement per line

Then fixing that might make sense. :-)

I don’t think the alternative to let-else is too bad.

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

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

No, that stuff is much much older.

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 think the name problem is overblown, you can always have an annotation to facilitate name changes.

In addition to that, I have my own list of things Rust should not have shipped with, but did.

I would be deeply uncomfortable to work in an environment where one couldn’t ask the author of a change for insights or rationale, because the author let some machine write it and therefore lacks any deeper understanding.

Only if you like “eventual consistency”, in the sense of “eventually, your data is consistently gone”.

Absolutely delusional.

code that is readable, auditable, and easy to port

Yeah C is the language that comes to everybody’s mind reading that. /s

C’s simplicity …

Is that simplicity currently in the room with us?

… and widespread adoption make it the best choice for this philosophy.

Ah, the asbestos argument.

If people want to run the latest kernels on hardware that isn’t maintained anymore, they need to toughen up and send patches …

… or they stick to an old kernel for their unmaintained hardware.

Both is fine to me, but that entitled Boomer attitude of “nobody should have nice things, because that would challenge status quo” needs to die.

“apparently it’s a better safer C++, but I’m not going to switch because I can technically do all that stuff in C++”

The main difference between C++ and D was that (for most of the time in the past) D required a garbage collector.

So, D was a language with similar Algol-style syntax targeting a completely different niche from C++.

Trying to correct your quote, it should read something like “I’m not going to switch because I can’t technically do all that stuff in D that I’m doing in C++” for it to make any sense.

Packages are usually provided by distribution packagers, not by the developers of the code itself.