I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.

[piecritic@hachyderm.io]

@fasterthanlime @arichtman @pndc invent a concept of restricted or external traits and go insane at the consequences

[piecritic@hachyderm.io]

@samir @lutzky @fasterthanlime I have done experimental crimes in the past on this, and to a large extent this is possible.

The problem is of course the infinite number of edge cases and the fact that, in practice, you'd need to use the C ABI to have nice things. And the C ABI is the antithesis of nice things.

[gronkulus@app.wafrn.net]

The ability to be generic over const/mut references - I very often find myself writing get and get_mut methods for the same things. You can hack together a version of this with GATs but it really deserves dedicated syntax, or better yet a single system to abstract over mut-ness, async-ness and const-ness.

[zwol@masto.hackers.town]

@soc @fasterthanlime I've never written the whole thing down, no.

Looking at your list, I would also have proposed [] instead of <> for generics, and smushing :: into . by whatever means necessary. I'm indifferent to = instead of : for key/value pair literals. Many of the other things feel uncomfortable as a knee jerk reaction but maybe I could get used to them. I think you're wrong about what macros get used for.

[zwol@masto.hackers.town]

@soc @fasterthanlime

Here's a few more things on my list but not yours:

The dereference operator (unary *) should be postfix. C got this wrong in 1970 and we've been paying for it ever since.

&& and || should have equal precedence and be non-associative wrt each other — this mandates what everyone actually does in practice, writing explicit parens whenever they are mixed.

#[path = "boo.rs"] mod foo; should be spelt mod foo = "boo.rs"; and it should be required for all out-of-line modules.

[lutzky@ohai.social]

@fasterthanlime bonus points if it's reversible. That is, I'd like to stick #[!author_is_lazy_just_gc_everything] on the top, and:

1. Write new code like the lazy bastard I am
2. Be able to go "oh shit, ot does need to be fast" later, remove it, receive the justice of compiler errors
3. Decide "this fast code needs maintenance but I am lazy" - stick the #[!thing] on top on preexisting, correct rust code, and only then add stuff.

[soc@chaos.social]

@zwol @fasterthanlime Oh, I agree on that!

I have put that in a non-Rust-specific article here:
https://soc.me/languages/unary-operators-are-unnecessary

[cuchaz@gladtech.social]

@fasterthanlime I'd fix whatever language/compiler defects cause async streams to be SO BAD to create.

[zwol@masto.hackers.town]

@soc @fasterthanlime I cannot agree with dropping prefix unary negation operators. Too much of a divergence from math notation.

And I think dereference does need an operator, not a method, I just think it belongs on the right. I'm not sure about enreference (unary &); it feels natural to put it on the left but maybe that's 40 years of C talking.

Rust has a thing where sometimes you have to write &*(expr) or *&(expr) and all of *those* cases should be intrinsic methods, yeah.

[ids1024@mathstodon.xyz]

@fasterthanlime Linear types (I believe that term is correct; the term is sometimes used for Rust's existing model, but that's more properly "affine").

So you could define a type that instead of having a destructor, is required to be passed to a function consuming it instead of allowing it to fall out of scope.

[soc@chaos.social]

@zwol @fasterthanlime I'm fine with the idea of requiring explicit parentheses, though I prefer a more conservative approach of

- fixing broken precedences inherited from C, and
- having fewer binary operators in general, and
- subsequently having fewer precedence levels

Applying all that, one ends up with ~5 precedence levels and <10 operators (not including comparison operators):

Language Design: Binary Operators are Overused

TL;DR: Use methods.

(soc.me)

That kinda solves all my concerns I have with binary operators.

[soc@chaos.social]

@fasterthanlime Probably throw out the whole rather useless `PartialOrd`/`Ord` and `PartialEq`/`Eq` hierarchies, then pick better names, then implement all replacement traits for floats.

[simonomi@mstdn.social]

@fasterthanlime Swift-style argument labels! IMO the most underrated feature that literally every programming language would be better off with (clearer APIs with no downside!!)

[nanobot248@mtd.sysblog.at]

@fasterthanlime i would add a compiler-supported `declaration_of!(some-struct-or-trait-name)` macro that is replaced with the trait declaration (aka the trait def without code blocks) or the struct declaration (struct field definitions and a list of all implemented traits).
that way it would be possible to auto-generate struct proxies, e.g. when composing multiple types or for newtypes.

[vbfox@hachyderm.io]

@fasterthanlime the orphan rule.

[michalfita@mastodon.social]

@fasterthanlime Just stuff I remember now, there was more:

1. `Arc<>::clone()` gives me goosebumps

[michalfita@mastodon.social]

@fasterthanlime Just stuff I remember now, there was more:

2. lack of declaration distinction between dyn safe and dyn non-safe traits, so compiler cannot restrict us before use

[octorine@fosstodon.org]

@cyberia @fasterthanlime My toy language has tuples, which are like in rust, and variants, which are anonymous enums where the constructors are numbered rather than named.

I also defined my enums as just enums, not enums of structs.

[octorine@fosstodon.org]

@fasterthanlime Hottest take here. I would get rid of multi argument functions. We already have tuples. Every function should take one argument and return one value.

[boxdot@chaos.social]

@fasterthanlime Replace Pin<T> by &pin T.