<div dir="auto"><div dir="ltr"><span></span></div><div dir="ltr">I just had to change a void function to a non-void function in <<a href="https://bugs.webkit.org/show_bug.cgi?id=195281" target="_blank">https://bugs.webkit.org/show_<wbr>bug.cgi?id=195281</a>>. 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.</div><div dir="ltr"><br></div><div dir="ltr">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 ;)</div><div dir="ltr"><br><div dir="ltr">Dan</div><div dir="ltr"><br>On Feb 21, 2019, at 10:32 PM, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>> wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Feb 21, 2019 at 9:31 AM Darin Adler <<a href="mailto:darin@apple.com" target="_blank">darin@apple.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">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!<br>
<br>
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.<br>
<br>
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.<br>
<br>
- 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.<br></blockquote><div><br></div><div>Perhaps this is the key distinction we want to make. Maybe if the <i>intent</i> 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 <i>intent</i> 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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
- 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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>- R. Niwa</div></div></div>
</div></blockquote><blockquote type="cite"><div dir="ltr"><span>______________________________<wbr>_________________</span><br><span>webkit-dev mailing list</span><br><span><a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a></span><br><span><a href="https://lists.webkit.org/mailman/listinfo/webkit-dev" target="_blank">https://lists.webkit.org/<wbr>mailman/listinfo/webkit-dev</a></span><br></div></blockquote></div></div>