[grok2]

Anybody else found the last variation annoying from a C perspective? I find that people coming from a web background don't mind writing complex statements in function parameters (seems like due to writing lambdas/closures and such encourages this kind of programming; maybe it makes sense in a lazy evaluation environment), but people with a C background use the last-but-one variation where you use an intermediate variable to capture a prior result to use as a function parameter. I myself prefer the last-but-one variation and it's a pet-peeve of mine that people write large functions/expressions/statements as function parameters when not needed all in the name of conciseness -- I think it affects readability.

[_bxg1]

In my Rust code I go back and forth. Coming from JavaScript, I started out trying to do everything in functional expressions - which Rust does as good a job of accommodating as it can - but Rust often requires so much more verbosity (.expect().unwrap().clone()...) that I found myself using local variables again.

And what I realized was that, as fashionable as it is to say these days that imperative code is the devil, Rust's (deeply) const-by-default local variables remove one of the main reasons people have for nesting their expressions inline: avoiding the creation of state that has the chance to be mutated. And I also found that giving names to those intermediate steps can really help improve legibility. For me, Rust has made imperative code cool again, while also allowing for maximally expressions-based code (even more than JS in some ways!) where it makes sense.

[steveklabnik]

I probably would not write the code that way either, but it's really hard to say how I would, given that it's not a realistic example.

This is one of the hardest parts about writing examples: you want something that's real, but also not long. Very difficult.

[thrower123]

Generally, I like to keep the temporaries. Mostly it is a consequence of getting burned and trained by the Visual Studio debugger; trying to put anything too complicated into the watch window or even evaluating it in the immediate window tends to be an exercise in frustration. It's also easier to step into the sub-expression/function call if need be when I do this, which is not always the case if it is a parameter to another function.

[Sammi]

I feel like there is some law in the universe that says that if I don't use an intermediate variable, then I will for certain need that intermediate variable some time later when I'm debugging.

[pm215]

In particular, you can give the intermediate result a useful name (using something more descriptive than 'n' would have helped in the example)...

[k__]

You mean, you have to give the intermediate results a useful name.

In my experience, this gets ugly rather quick.

But yeah, I hope the pipeline operator comes soon, chaining is nice, but nesting can get quite messy.

[phkahler]

>> it's a pet-peeve of mine that people write large functions/expressions/statements as function parameters when not needed all in the name of conciseness -- I think it affects readability.

Worst thing ever. I was trying a gfx-rs example to do some drawing. One smallish function took another function as a parameter (a closure actually) so they just wrote an entire drawing function inline. The pipes helped clue me in that something strange was going on.

My own code pulled that function out into a clean definition eventually. As it should have been in example code.

It's not in the name of conciseness. Not sure what it is, but it's not that.

[dmix]

That looks a bit unusual even from a FP perspective. Functions get passed to functions all the time, just not defined inline very often. Unless it's the only one parameter or a very simple closure, then it could still look clean and readable.

[jcora]

I use almost no lambdas in my functional code. I don't understand why they're thought to be paragons of FP in non-pure language communities. Maybe because there are no operator sections, currying, and the syntax is more verbose so it's not as easy to define helpers.