4 ms·

"return" is good because it signals intent. It lets you communicate to both the compiler and at least as importantly, to the reader, that this is the value you

"return" is good because it signals intent. It lets you communicate to both the compiler and at least as importantly, to the reader, that this is the value you intended this function to return. The compiler can then warn you if you return a value when you weren't meant to, or if you forgot to return one when you were. And the reader can tell at a glance that this value is important.

mpweiher 5y ago
Yeah, that's one of the good reasons for having a return statement. I don't know if it outweighs the reasons not to have a return statement (yet). Another issue is that there are actually 2 functions of the return statement: (1) it sends a result and (2) it terminates the method/function/whatever. In call/return, those are the same, but more generally they are not, and Objective-S wants to make it easy to not default to call/return semantics. And that's difficult, because we are so incredibly used to call/return semantics that it's often hard to see that another way is even possible, let alone practical. So in the design, I need to very deliberately push against what seems comfortable and familiar. Which can lead to insights or nonsense. We'll see how it turns out.
- ghusbands 5y ago
  Having implicit returns has been a source of bugs and vulnerabilities in code [1][2][3]. Essentially, it results in accidental return of temporary values, especially in cases in which people don't want to return anything. [1] https://github.com/CodeNarc/CodeNarc/issues/450 https://github.com/CodeNarc/CodeNarc/issues/450 [2] https://stackoverflow.com/questions/24070544/suppressing-implicit-returns-in-swift https://stackoverflow.com/questions/24070544/suppressing-imp... [3] https://nug.xojo.narkive.com/GvvcWglM/bug-command-keys-are-absorbed-by-menu-handlers-on-mac-but-not-on-windows https://nug.xojo.narkive.com/GvvcWglM/bug-command-keys-are-a...
  - slver 5y ago
    If you don't want to return anything you'd declare your function return type as void, so that's probably more in dynamically typed systems.
    - magicalhippo 5y ago
      We've had cases at work where the issue is that a void function (procedure) is converted to a "proper" function, and some return paths are missed. For our compiler, for certain types it fails to warn that the return variable is unassigned, hence bugs occur. This is a statically typed language, it's just an unfortunate interaction between compiler magic and the code that checks for unassigned return variables.
slver 5y ago
With a bit of practice, the intent of "the last expression is the one you return" is clear enough. That's not a problem I think. The problem is how to encode early returns in that context.
- user-the-name 5y ago
  With a little bit of practice, you can get used to anything that reduces comprehensibility. That doesn't mean doing it is a good idea. Every time you do, you sacrifice a bit more.
  - slver 5y ago
    Come on, that's not what I meant. "Last line of a function" is honestly a very blatant and obvious way of encoding a returning point (and hence returning expression in an expr-oriented language). You literally can't miss which line is the last line, UNLESS you're simply habituated into seeing the keyword "return". You said it's about communicating intent, not about matching current habits. Those are completely different things. For example, someone who knows Russian and is learning English, so they make mistakes in English. That doesn't mean English is a poor language for communication, does it? Case in point, do you actually type "return" in say Java, for a void method, when that return is your very last line of the method? Yes, no? If no, then you didn't need to communicate "it's returning here" with greater intent. If yes, then I'll accept your point about you finding no return ambiguous. But still, most people don't.
    - user-the-name 5y ago
      But it's not the last line of a function, though, is it? Put an if statement in there, and it can be literally any line of the function. Sure, you can still work out which one, but it gets more difficult. And, even if it were the last line of the function, you are still not communicating clearly whether the function is meant to return a value at all or not. This both hurst readability, and makes it easier to accidentally introduce bugs.
      - 5y ago

mpweiher 5y ago

Yeah, that's one of the good reasons for having a return statement. I don't know if it outweighs the reasons not to have a return statement (yet). Another issue is that there are actually 2 functions of the return statement: (1) it sends a result and (2) it terminates the method/function/whatever. In call/return, those are the same, but more generally they are not, and Objective-S wants to make it easy to not default to call/return semantics. And that's difficult, because we are so incredibly used to call/return semantics that it's often hard to see that another way is even possible, let alone practical. So in the design, I need to very deliberately push against what seems comfortable and familiar. Which can lead to insights or nonsense. We'll see how it turns out.

ghusbands 5y ago
Having implicit returns has been a source of bugs and vulnerabilities in code [1][2][3]. Essentially, it results in accidental return of temporary values, especially in cases in which people don't want to return anything. [1] https://github.com/CodeNarc/CodeNarc/issues/450 https://github.com/CodeNarc/CodeNarc/issues/450 [2] https://stackoverflow.com/questions/24070544/suppressing-implicit-returns-in-swift https://stackoverflow.com/questions/24070544/suppressing-imp... [3] https://nug.xojo.narkive.com/GvvcWglM/bug-command-keys-are-absorbed-by-menu-handlers-on-mac-but-not-on-windows https://nug.xojo.narkive.com/GvvcWglM/bug-command-keys-are-a...
- slver 5y ago
  If you don't want to return anything you'd declare your function return type as void, so that's probably more in dynamically typed systems.
  - magicalhippo 5y ago
    We've had cases at work where the issue is that a void function (procedure) is converted to a "proper" function, and some return paths are missed. For our compiler, for certain types it fails to warn that the return variable is unassigned, hence bugs occur. This is a statically typed language, it's just an unfortunate interaction between compiler magic and the code that checks for unassigned return variables.

slver 5y ago

With a bit of practice, the intent of "the last expression is the one you return" is clear enough. That's not a problem I think. The problem is how to encode early returns in that context.

user-the-name 5y ago
With a little bit of practice, you can get used to anything that reduces comprehensibility. That doesn't mean doing it is a good idea. Every time you do, you sacrifice a bit more.
- slver 5y ago
  Come on, that's not what I meant. "Last line of a function" is honestly a very blatant and obvious way of encoding a returning point (and hence returning expression in an expr-oriented language). You literally can't miss which line is the last line, UNLESS you're simply habituated into seeing the keyword "return". You said it's about communicating intent, not about matching current habits. Those are completely different things. For example, someone who knows Russian and is learning English, so they make mistakes in English. That doesn't mean English is a poor language for communication, does it? Case in point, do you actually type "return" in say Java, for a void method, when that return is your very last line of the method? Yes, no? If no, then you didn't need to communicate "it's returning here" with greater intent. If yes, then I'll accept your point about you finding no return ambiguous. But still, most people don't.
  - user-the-name 5y ago
    But it's not the last line of a function, though, is it? Put an if statement in there, and it can be literally any line of the function. Sure, you can still work out which one, but it gets more difficult. And, even if it were the last line of the function, you are still not communicating clearly whether the function is meant to return a value at all or not. This both hurst readability, and makes it easier to accidentally introduce bugs.
    - 5y ago