31
things rust shipped without (2015) (graydon2.dreamwidth.org)
you are viewing a single comment's thread
view the rest of the comments
[-] soc@programming.dev 2 points 1 month ago* (last edited 1 month ago)

Thanks for your reply, some replies below!

requiring positional args to use the assignment syntax

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.

But you’re also missing one use of the impl keyword: fn func() -> impl Trait.

That removal could actually happen, so I didn't list it. (Rust started requiring dyn and disallowed naked trait returns with edition 2018. So dropping the impl in that position might not be completely impossible like the other uses of impl.)

Are you suggesting using keywords/methods [for array and slice syntax] instead?

Yes, just methods.

I can understand someone preferring the PartialEq/PartialOrd behavior

You can have both – that's what's being made possible by them not being in a hierarchy.

I think if-let makes sense, but don’t expand it.

It's a bit late for that, isn't it? ;-)

Why? What value does -> () provide? Why not elide that?

What value is provided by keeping it? Why a syntactic special-case for exactly that type and not any other random type?

languages w/o them feel awkward since you’re generally limited to one statement per line

Then fixing that might make sense. :-)

[-] anton@lemmy.blahaj.zone 1 points 1 month ago* (last edited 1 month ago)

But you’re also missing one use of the impl keyword: fn func() -> impl Trait.

[...] So dropping the impl in [return position] might not be completely impossible like the other uses of impl.

But the impl markes that it is a trait to the programmers.
Take the following functions:

func1()->A{...}
func2()->A{...}

Does the following snippet compile?

let mut thing = func1();
thing = func2();

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.


Why? What value does -> () provide? Why not elide that?

What value is provided by keeping it?

What value does cluttering up your code with -> () provide?

Why a syntactic special-case for exactly that type and not any other random type?

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.


languages w/o [semicolons] feel awkward since you’re generally limited to one statement per line

Then fixing that might make sense. :-)

It's fixed with semicolons ;-)

this post was submitted on 01 Sep 2025
31 points (94.3% liked)

Rust

7418 readers
24 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

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