I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc.
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@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.
-
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.
@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 levelsApplying 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.
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@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.
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@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!!)
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@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. -
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@fasterthanlime the orphan rule.
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@fasterthanlime Just stuff I remember now, there was more:
1. `Arc<>::clone()` gives me goosebumps
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@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
-
@fasterthanlime I think I'd allow anonymous structs/enums. Often I find myself reaching to create an enum field inside a struct and it's annoying having to make a whole separate named declaration for it.
@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.
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@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.
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@fasterthanlime Replace Pin<T> by &pin T.
-
@fasterthanlime I think I’d just make tokio part of the standard and avoid the async function colouring problem. Then spend time on the compiler to be smart about the actually necessary async inclusion vs compiling to sync
@tribaal @fasterthanlime I think other languages promised that, and they could not deliver on these promises.
-
@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!!)
@simonomi @fasterthanlime I don't feel they add much benefit on top of named arguments ... is there a good argument to not spend that language complexity elsewhere?
-
@fasterthanlime the orphan rule.
@vbfox what's the alternative?
-
@simonomi @fasterthanlime I don't feel they add much benefit on top of named arguments ... is there a good argument to not spend that language complexity elsewhere?
@soc @fasterthanlime by "named arguments" do you mean something akin to python-style kwargs? or maybe LSP inlay of argument names at callsites?
a lot of the value of argument labels comes from them being manditory and chosen by the callee. i really value Swift's API design tenet of "clarity at the point of use", and even the simple aesthetic change of going from `sayHi(person)` to `sayHi(to: person)` can make a big difference IMO
-
@soc @fasterthanlime by "named arguments" do you mean something akin to python-style kwargs? or maybe LSP inlay of argument names at callsites?
a lot of the value of argument labels comes from them being manditory and chosen by the callee. i really value Swift's API design tenet of "clarity at the point of use", and even the simple aesthetic change of going from `sayHi(person)` to `sayHi(to: person)` can make a big difference IMO
@soc @fasterthanlime aside from clarity, being able to 'overload' on argument labels is really really nice, and Rust deals with a lot of same-method-but-with-try/mut-instead already
-
I am NOT making a Rust replacement, but — if you could fix one* thing about Rust syntax/semantics/etc. what would you fix?
(*one per reply, multiple replies per household are allowed)
@fasterthanlime this one is a bit tongue-in-cheek, but i think nearly every programmer/language designer has something to learn from the Swift API design guidelines. if Rust could just steal that in its entirety (and probably improve upon it!) that'd be perfect
Swift.org
Swift is a general-purpose programming language built using a modern approach to safety, performance, and software design patterns.
Swift.org (swift.org)
-
@tribaal @fasterthanlime I think other languages promised that, and they could not deliver on these promises.
@soc @fasterthanlime which language tried to abscond the “runtime machinery” if possible at compile time? Genuine question. I know at least one language without function colouring problem for async, but to my knowledge it always includes a runtime (golang)
-
Unfortunately the ecosystem is split between colored functions and coloured functions
@fasterthanlime maybe we can try to get the ecosystem united by compromising and spelling it coulored from now on?
-
@vbfox what's the alternative?
There are various ways we could relax it a little. Allow top-level crates to implement arbitrary traits for arbitrary types. Allow libraries to opt-in to having new impls for their traits/types. In general, I'd love to see it become possible to integrate crate A with crate B using crate AB, rather than A or B; that would remove a major scaling issue and source of lock-in in the ecosystem.
