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 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. -
@vbfox what's the alternative?
@fasterthanlime naming of trait implementations then an explicit way to bring one of them into scope (“use” ?) and a way to specify them per-callsite.
The current syntax would be the equivalent of allowing anonymous implementations that are automatically applicable to any scope where no other named implementation has been specified.
impl Clone as MyClone for u32 {
use lib::MyClone;
// or
let x: u32 + MyClone = 42; -
@chosunone @fasterthanlime I think this just comes down to making the borrow checker (static analysis) more intelligent so that you can have more granular *borrows*, right?
Actually marking the fields as mutable or immutable doesn’t make much sense to me either, so I guess you’re suggesting either new syntax when borrowing or else a smarter borrow checker?
(It’s a tension point to be sure but I don’t hit it very often)
@ianthetechie
@fasterthanlime
It's not just that. It's a guarantee that a field can never change on a structure despite other fields being mutable even with a mutable borrow existing on the entire structure. It's also useful for providing an api with public fields that shouldn't be mutated. To do that now you have to make a public getter on a private field, and then that prevents mutable borrows of the structure.
