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.
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).
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.
The “drop the array and slice syntax” is just nuts. With 0 justification.
I’m curious, have you used Rust much? Most of those changes just feel like “rust should be more familiar to me” changes.
Also:
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.
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 (likedef foo(a, *, b)for example).No, that stuff is much much older.
I think the name problem is overblown, you can always have an annotation to facilitate name changes.