this post was submitted on 01 Sep 2025
29 points (93.9% liked)
Rust
7487 readers
26 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Thanks for your reply, some replies below!
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.
That removal could actually happen, so I didn't list it. (Rust started requiring
dynand disallowed naked trait returns with edition 2018. So dropping theimplin that position might not be completely impossible like the other uses ofimpl.)Yes, just methods.
You can have both – that's what's being made possible by them not being in a hierarchy.
It's a bit late for that, isn't it? ;-)
What value is provided by keeping it? Why a syntactic special-case for exactly that type and not any other random type?
Then fixing that might make sense. :-)
But the impl markes that it is a trait to the programmers.
Take the following functions:
Does the following snippet compile?
Under the current rules we know it will. But if A could be a trait, the functions could return different types. We currently mark that with the
impl.What value does cluttering up your code with
-> ()provide?Because the unit type is special, just like the never
!type.()also has the special importance of being the return value of an empty statement and some other stuff.It's fixed with semicolons ;-)