• Post Reply Bookmark Topic Watch Topic
  • New Topic

implicit return?  RSS feed

 
J Solomon
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does Java not have an implicit return? I would expect if I write a function with return type 'int' and within that function I call another function that returns 'int', then I would not have to explicitly declare 'return'. When I test this theory out, I see that I am wrong:



Javac output:
Test.java:13: error: missing return statement
}
^
1 error


So you must define bar() as such:



Am I missing something here, I would assume that since bar() is calling foo() which has an explicit 'return', then you would not have to explicitly declare return within bar(), or is there no implicit return in Java?
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You must declare the return.
 
Joe Harry
Ranch Hand
Posts: 10128
3
Eclipse IDE Mac PPC Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are you coming from a functional programming world? After getting used to Scala's implicit return types, I feel Java is a bit verbose. Hope some of those nice features like implicit return statements make it to Java 9 or 10 or later.
 
J Solomon
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I feel most languages today implement an implicit return.........Python, Ruby, even Groovy has an implicit return and it's built on top of Java.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joe Harry wrote:Are you coming from a functional programming world? After getting used to Scala's implicit return types, I feel Java is a bit verbose. Hope some of those nice features like implicit return statements make it to Java 9 or 10 or later.

Hmmm. Methinks they may have more important things to worry about...

The rule in Java is simple: Unless the return type is void, the last statement - unless a block (eg, a switch block) that precludes it is involved - must be a return, which is consistent with C/C++ syntax.

But maybe I don't fully understand the benefits of implicit returns. Perhaps you could explain why you like it?

Winston
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote:Perhaps you could explain why you like it?


I'll explain why I don't like a lot of implicitness. Sure, Java can be verbose about a lot of things (the most egregious in my mind alleviated somewhat with Java 8), too much implicitness in a language has a negative impact on clarity and readability. I really wanted to like Scala -- really, I did -- but the degree to which code can be reduced via "shortcuts", and the absolute glee that Scala developers seem to take in making code as compact and unreadable as possible, has rather soured me on the language.

I'll take a bit of verbosity if it aids clarity, and I'll take implicitness until the point that it affects clarity.

But maybe that's just 'cause I'm a grumpy ol' developer.

 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:I'll explain why I don't like a lot of implicitness...

Hey, I'm with you, Grumpy. I always put in my own constructor calls, and my default constructors, and extends Object ... and probably a few other things I've forgotten. Don't even know why the Java Gods decided it was a good idea to have the compiler write 'em for you.

Winston
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd feel that adding extends Object is too far on the spectrum for even me, but I do add this. to the front of all references to member variables, so I'm not one to talk!
 
sai rama krishna
Ranch Hand
Posts: 536
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do not know much of other programming languages. I feel comfortable to see return in the code and favor more for explicit things which make readability easy.
 
J Solomon
Ranch Hand
Posts: 30
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bear Bibeault wrote:I'd feel that adding extends Object is too far on the spectrum for even me, but I do add this. to the front of all references to member variables, so I'm not one to talk!


I almost always add this. to the front of all member vars, makes code much easier to read, especially if your formal parameters are going to shadow your member vars.
 
Bear Bibeault
Author and ninkuma
Marshal
Posts: 66307
152
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
J Solomon wrote:I almost always add this. to the front of all member vars, makes code much easier to read.

I agree. Perhaps even more importantly to me, it makes the code consistent. There are times when this. must be used, and by always using it, references to the variable are consistent throughout the code.
 
Matthew Brown
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think the idea of "implicit return" (if that's what you'd call it) makes perfect sense in a functional language. The point is that "return" is an imperative concept, so using it goes against the whole paradigm you're trying to use. In a pure functional language everything is simply an expression to evaluate, and a sequence of expressions evaluates to the last one. I don't really see it as an implicit return.

It's a bit less clear when you're mixing paradigms, though. I don't use return statements in Scala because I'm trying to be as functional as possible (many functional languages don't even have the option). In Python or Ruby I'd be tempted to leave them in.
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, I am feeling in procedural object logical imperative mode. To the Batmobile Java Language Specification (=JLS)!!

There is such a thing as abrupt completion and there is such a thing as normal completion. And there is a nice simple explanation of the difference in the JLS. If you write return that is abrupt completion and if you don't have a return statement that's normal completion. (Unless you have an Exception or something.) Now, if you had implicit return, wouldn't that convert normal completion to abrupt completion? Doesn't that make implicit return in Java a contradiction in terms?
And this is not just an argument about words. If you have a return in a try and a return in a catch and a return in a finally, which value is actually returned? It was discussed in this recent thread, and it is important whether a particular statement terminates normally or abruptly.
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A few minutes ago, I wrote: . . . nice simple explanation . . .
… and I was lying horribly.
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you inspect the bytecode of a method with the javap tool, you find that each method ends with “return” but I think that is something different.
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moving discussion as too difficult for “beginning”.
 
Piet Souris
Master Rancher
Posts: 2044
75
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Funny.

I remember putting a cry for help, somewhere early May, in the Scala forum.
I had written a function, and that function didn't work, due to a complete
miunderstanding of this 'implicit return'.
No returns and no semi colons? I felt completely lost by then.

But you know? A couple of days later it all became clear to me, and it
surprised me how fast it all becomes second nature. I truelly found the
Scala syntax a big pleasure to work with. Apart from the functional
part, a lot of the Scala syntax is about ease of use.

And indeed, like in APL and Python, there are full opportunities to
misuse it, and to produce very short, but incomprehensible code. But that
is up to the user to handle this wisely.

Meanwhile, I'm back to using returns and semi colons... I feel like
going back to medieval times.

And lastly: using 'this' is something I do too. In an IDE, it has the
advantage that after typing the dot, up pops a window with all
possibilities.

Greetz,
Piet

 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:If you inspect the bytecode of a method with the javap tool, you find that each method ends with “return” but I think that is something different.

Dunno, but that suggests to me that maybe all methods end abruptly, because the only place I'm not obliged to put in an explicit return statement is in a void method; and if the compiler sticks one in for me anyway...

I'm also not quite sure where all this business of normal and abrupt termination gets us. It seems to be something that might be of interest to someone writing their own JVM but, as I said in the thread you linked, I managed to get through 13 years without reading that section in detail. I also understand that abrupt termination could leave a program in an inconsistent state, but if it arises simply as a result of the execution of another statement (return) the distinction seems rather meaningless, since in 98 (and possibly 100) percent of cases I have no choice about explicitly returning from a method.

But maybe I'm wrong. It's been known...

Winston
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Winston Gutkowski wrote: . . .
Dunno, but that suggests to me that maybe all methods end abruptly, because the only place I'm not obliged to put in an explicit return statement is in a void method; and if the compiler sticks one in for me anyway...
. . .

Winston
As I said the return added by the compiler must be something different otherwise as you say everything would complete abruptly. It probably means that the stack frame has a record of where the method was called from and return tells the VJM to wind the stack pointer back to that location.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:As I said the return added by the compiler must be something different otherwise as you say everything would complete abruptly.

That's not how I read the section. For example, you're specifically not allowed to put a return in an initializer block or a constructor.

It probably means that the stack frame has a record of where the method was called from and return tells the VJM to wind the stack pointer back to that location.

But since the simple presence of a return statement (required if a method returns anything other than void) causes the method to end abruptly, doesn't that mean that the only way for it not to is if it's a void method that simply "drops out"? That's why I find the distinction a bit meaningless.

Winston
 
Campbell Ritchie
Marshal
Posts: 56599
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes. The only way to terminate a method “normally” is to declare it void.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Conceptually, the JVM bytecode return instruction is not the same thing as a return statement. The JLS does not talk at all about bytecodes; that's an implementation detail, out of scope for the JLS. A Java language return statement may indeed be implemented by a JVM return bytecode - but that does not mean that all return bytecodes are equivalent to Java language return statements.

More importantly though, the return, break, and continue statements can cause abrupt completion of statements - but not of methods. More specifically, return/break/continue cause abrupt completion of themselves, and they may also cause abrupt completion of control statements that contain them. I.e. abrupt completion of if/else, for, while, or do/while statements that contain them. Nothing else.

Abrupt completion of a method is handled by the rules for abrupt completion of expressions. And expressions only complete abruptly if an exception is thrown.

So, if a return/break/continue statement is encountered, that statement completes abruptly. Some of the containing control structures (if/else/for/while/do) may also complete abruptly. But the containing method completes normally. Unless an exception is thrown.
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To address the original question, I would note that Java 8 does allow an implicit return inside a lambda expression. Though they don't seem to call it that in the JLS, for reasons not immediately clear. But the point is, you can omit "return" in a lambda, if the lambda is a one-line expression. Doesn't work for a sequence of statements, though.
 
Winston Gutkowski
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mike Simmons wrote:...So, if a return/break/continue statement is encountered, that statement completes abruptly. Some of the containing control structures (if/else/for/while/do) may also complete abruptly. But the containing method completes normally. Unless an exception is thrown.

Aaah. Thanks for that, Mike. I noticed that the section seemed to be about statements, but I also noticed that the explanation included stuff about blocks; and I assumed that a method was simply a specialized form of block.

And I still wonder why this would be of much use to a Java programmer. Like I say, I managed 13 years before I got into this discussion...

Winston
 
Mike Simmons
Ranch Hand
Posts: 3090
14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yeah, this definition doesn't seem particularly useful. It's mostly needed for understanding other parts of the JLS that rely on that definition. Those parts probably could have been rewritten in other language, with about the same number of words. But most of us don't really need to know one way or another, I think.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!