I just had to change a void function to a non-void function in < https://bugs.webkit.org/show_bug.cgi?id=195281>. I was very happy that all of the existing code was written by people that did not return void because I didn't have to change any call sites returning void into two lines. This saved me time, kept the patch minimal, avoided dirtying line history, and avoiding me having to do a double-take whenever I see a return void.
Is there a path forward for this issue? Should I put together an online survey for people to vote? I don't want this issue to fall into a void ;) Dan On Feb 21, 2019, at 10:32 PM, Ryosuke Niwa <rn...@webkit.org> wrote: On Thu, Feb 21, 2019 at 9:31 AM Darin Adler <da...@apple.com> wrote: > I tried not to weigh in on this, but my view on the materials we should > use to build the bike shed must be shared! > > Generally it seems neat to be able to make the code slightly more tight > and terse by merging the function call and the return into a single > statement. > > Other than not being accustomed to it, I have noticed three small things I > don’t like about using “return” with a call to a void-returning function. > > - You can’t use this idiom when you want to ignore the result of a > function, only if the function actually returns void. Often functions are > designed with ignorable and often ignored return values. For example, it’s > common to call something that might fail and have a good reason to ignore > whether it failed or not. The idiom we are discussing requires treating > those functions differently from ones that return void. If you refactor so > that a function now returns an ignorable return value you need to visit all > the call sites using return and change them into the two line form. > Perhaps this is the key distinction we want to make. Maybe if the *intent* is to ignore the function's return value regardless of what it may return in the future, then we should have a separate "return". If the *intent* is to return whatever that other function returns, then we should return void. But having to think about the intent of code isn't a great thing for coding style guideline. - It works for return, but not for break. I’ve seen at least one case where > someone filled a switch statement with return statements instead of break > statements so they could use this more-terse form. Now if we want to add > one line of code after that switch, we need to convert all those cases into > multi-line statements with break. > This is an orthogonal point but I do prefer switch'es that return directly over one that break's then having a separate return after the switch statement especially if the switch statement is long. I've gotta say I'm fascinated to learn that many people are bothered by returning void. I guess I was never bothered by it because I see a return statement as a thing that returns the control back to the caller, not a thing that returns a value. - R. Niwa _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
