In more ways than one, programmers are born to have strong opinions about tiny things, and here are 5 of mine. Follow these 5 tips--or disagree with them veh...
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.
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?
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.
2
was good, thanks.4
needs a tad more thought imho, returning animpl T
does have its place, because it makes changing the return type of the function a non-breaking change.Number 4 is only about not returning
impl Into
and instead just returningT
.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?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 notinto
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.