this post was submitted on 01 Sep 2023
17 points (87.0% liked)

Rust

6055 readers
106 users here now

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

Wormhole

[email protected]

Credits

  • The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago
MODERATORS
top 5 comments
sorted by: hot top controversial new old
[–] [email protected] 3 points 1 year ago

Here is an alternative Piped link(s): https://piped.video/watch?v=8j_FbjiowvE

Piped is a privacy-respecting open-source alternative frontend to YouTube.

I'm open-source, check me out at GitHub.

[–] KillTheMule 1 points 1 year ago (1 children)

2 was good, thanks. 4 needs a tad more thought imho, returning an impl T does have its place, because it makes changing the return type of the function a non-breaking change.

[–] 0xDEADBEEFCAFE 4 points 1 year ago (1 children)

Number 4 is only about not returning impl Into and instead just returning T.

[–] KillTheMule 1 points 1 year ago (1 children)

Hmm, right. I think it still might be warranted in niche cases, but trying to think of such a case made it pretty protracted in my head... maybe when functions can also be called for side effects, and the into conversion is costly and the caller might not care about the return value?

[–] [email protected] 1 points 11 months ago

Such a case would be the single function having a side effect*. This allows the caller to chose when to execute the side effect or to drop the result without executing it.

In my opinion that is fine with fn_once but not into because of the implicit contract of these traits.

* = I'm counting expensive computation, but not allocation and memcopy as a side effect in this comment.