10 ms·

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 e

by 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.
    - slver 5y ago
      It's just inescapable that your argument in fact requires explicit returns in mainstream languages whether you return value or not. Because the "does it return value or not" question doesn't sit in expression languages. They always return value.
      - user-the-name 5y ago
        Why do you say that as if it is not a problem in itself?
    - PoignardAzur 5y ago
      Yeah, in practice I have this problem with Rust sometimes. If the returned value is a single line, it's easy to see what is being returned. If it's a 10-lines if/else, and you don't remember the function's return type, and you're not sure how many layers of control flow you're at, etc, it gets a little ambiguous. You can mitigate that with good coding practice, though. There could maybe even be turned into lints.
layer8 5y ago
"Return" is much more reliable to spot (moreso with syntax highlighting) than having to identify the last expression, in particular in functional-style programming where expressions can take up many lines. One way to think about it is how assigning subexpressions to a descriptively named variable helps reader comprehension, instead of nesting everything into one big expression. "Return" fulfills a similar role. (In some imperative languages, the return value is defined by assigning it to the name of the function — or rather, to an implicitly declared variable having the same name as the function. While that design has some problems of its own (mutability, default values, naming), it exemplifies the analogy with descriptive variables noted above.)

by 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.
  - slver 5y ago
    It's just inescapable that your argument in fact requires explicit returns in mainstream languages whether you return value or not. Because the "does it return value or not" question doesn't sit in expression languages. They always return value.
    - user-the-name 5y ago
      Why do you say that as if it is not a problem in itself?
  - PoignardAzur 5y ago
    Yeah, in practice I have this problem with Rust sometimes. If the returned value is a single line, it's easy to see what is being returned. If it's a 10-lines if/else, and you don't remember the function's return type, and you're not sure how many layers of control flow you're at, etc, it gets a little ambiguous. You can mitigate that with good coding practice, though. There could maybe even be turned into lints.

layer8 5y ago

"Return" is much more reliable to spot (moreso with syntax highlighting) than having to identify the last expression, in particular in functional-style programming where expressions can take up many lines. One way to think about it is how assigning subexpressions to a descriptively named variable helps reader comprehension, instead of nesting everything into one big expression. "Return" fulfills a similar role. (In some imperative languages, the return value is defined by assigning it to the name of the function — or rather, to an implicitly declared variable having the same name as the function. While that design has some problems of its own (mutability, default values, naming), it exemplifies the analogy with descriptive variables noted above.)