Sybex 829 - Introduction Ixii errata

The explanation for answer 23 states that "Lambda expressions with one parameter are allowed to omit the parentheses around the parameter list, making option C correct".
However, when you look at option C, the parentheses are not omitted.

Additionally, it says "the return statement is optional when a single statement is in the body, making option F correct."
But option F has a return statement, and in fact has brackets around the body, meaning that the return statement is not optional at all.

Welcome to the Ranch

This question appears to be written not very clearly; somebody else got confused by it similarly last week: here, where you might find some more information. Please supply more information about the second question.
In both cases, I think there is confusion because in one case the (...) may be optional, and in another case because return may be optional.
In a λ, x ‑> 2 * x and (x) ‑> 2 * x are equivalent to each other, and both permissible.
Similarly, x ‑> 2 * x and x ‑> { return 2 * x; } are also equivalent to each other, and therefore both permissible.
Note that x ‑> return 2 * x without {...; } won't compile.

A few hours ago, I wrote:. . . the (...) may be optional . . .

I think people are getting confused about the first question because they forget that, “allowed to omit,” doesn't mean, “must omit.”

Thanks for the reply and for linking the other person's post, Campbell Ritchie.

Regarding answer C, what trips me up are not so much the rules regarding Lambda's and their various allowed syntaxes. Nor does the fact that answer C is correct surprise me. That much is quite clear to me.
Rather, what trips me up is the explanation of why answer C is correct.
Specifically, the explanation for answer C states that  "Lambda expressions with one parameter are allowed to omit the parentheses around the parameter list, making option C correct".

Sure, it is merely stated that parentheses are allowed to be omitted, and so you can infer that they may either be present or absent. In that sense, the explanation of this rule regarding lambda's contains no mistake.

But the fact that it is allowed to omit parentheses most certainly does not make option C correct. In fact, the fact that parentheses are allowed to be omitted has no relationship to the correctness of answer C at all, since in answer C the parentheses are not omitted.

Phrased differently, the stated rule is that parentheses may be omitted. The argument is that this rule makes option C correct.

But if this rule did not exist, option C would still be correct since it does not omit the parentheses.
How, then, can we argue that this rule is what makes option C correct?

This is the error that I attempted to point out.

As for answer F, it uses the following syntax
(i) -> { return i == 5; }
Similar to answer C, the explanation states that  "the return statement is optional when a single statement is in the body, making option F correct."
I suppose that technically, if the single statement is surrounded by brackets, then the return statement must be used. And if the brackets are omitted, then a return statement may not be used. So in that sense, one could argue that the return statement is somewhat optional.


But even if we apply such a lenient interpretation to the explanation, to state that answer F is correct specifically because the return statement is optional, when in fact the return statement is not optional for F due to the braces, strikes me as a mistake.

Ironically, the text then explains that for answer B, which was i -> { i == 5;}, that it is incorrect because a return statement must be used when braces surround the body.

The fact that the answer to B explains how the return statement is not optional when braces are present makes the mistaken explanation for F stand out all the more prominently.
The explanation to F says that the return statement is optional. The explanation to B says that it is not for a reason that also applies to F.

I, at least, find it hard to imagine that the authors intended the explanations to C and F to be this way.

Mitchell Coutinho wrote:Thanks . . .

That's a pleasure

. . . what trips me up is the explanation of why answer C is correct. . . . allowed to omit the parentheses . . . they may either be present or absent. . . .

Yes, as you will have seen from the link I showed you, the (...) may be present or absent if you reduce the parameter list to exactly one token. As I said, the wording of the question seems not to be clear to everybody. The Java® Language Specification (=JLS) says,

If a lambda expression has exactly one formal parameter, and the parameter is specified by an identifier instead of a parameter specifier, then the parentheses around the identifier may be elided.

. . . and I don't think that is much clearer.

As for answer F . . . if the single statement is surrounded by brackets, then the return statement must be used. . . .

Thank you for showing us the additional information about question F .
I am in Britain, so I use the word “bracket” slightly differently from people in the USA, but please call {...} “braces.”
Let's see whether the JLS can help: try this section. Yes, the grammar says that a LambdaBody (=part right of the ‑>) may be an Expression or a Block. If your λ for F reads i ‑> i == 5, then the body is an expression. If you look up the grammar for Block (use link on that JLS page), you will see it may contain any number (including 0) of declarations and statements, but it is not allowed to contain plain simple expressions. If you put braces {...} around the body of the λ, then you are saying it mustn't contain plain expressions. You can however get it to compile by changing all the expressions to statements by prefacing them with return.
If no custom type has been shown, I believe the type of the λ in question F is either a Predicate<Integer, Boolean> or an IntPredicate.

Yesterday, I wrote:. . . . Predicate<Integer, Boolean> . . . .

I think, if you look up the link, you will find I should have written Predicate<Integer>.

Yes, as you will have seen from the link I showed you, the (...) may be present or absent if you reduce the parameter list to exactly one token. As I said, the wording of the question seems not to be clear to everybody. The Java® Language Specification (=JLS) says,

If a lambda expression has exactly one formal parameter, and the parameter is specified by an identifier instead of a parameter specifier, then the parentheses around the identifier may be elided.

. . . and I don't think that is much clearer.

I appreciate the extra context. I did not find the explanation accompanying answer C to be all too confusing. I read the relevant section of the JLS that you were kind enough to reference. The section is also quite clear to me. I suspect that perhaps the rules regarding the use of parentheses were clear to Tim Mousaw as well when he submitted his feedback. The wording in his post suggests to me that the assertion made as to why answers C and F are correct are what he disagrees with, as I do.

I am in Britain, so I use the word “bracket” slightly differently from people in the USA, but please call {...} “braces.”

Hah, apologies. I'll try to keep that in mind

If no custom type has been shown, I believe the type of the λ in question F is either a Predicate<Integer, Boolean> or an IntPredicate.
...
I think, if you look up the link, you will find I should have written Predicate<Integer>.

Close enough! The question actually includes the functional interface in question. It was a Function<Integer, Boolean>.

In any case, I hope that this submission ends up being helpful for other readers taking the assessment test that could not find this in the errata on https://www.selikoff.net/ocp17/.
If this information is ever acknowledged as errata, I propose that Tim Mousaw is listed as the reporter for his initial post on the subject.

Mitchell Coutinho wrote:. . . a Function<Integer, Boolean>.

Damn! I had that in the back of my mind as a possibility and didn't write it down

In any case, I hope that this submission ends up being helpful for other readers . . . .

I am sure it will. We find people coming back to threads many years old and finding useful information there.

Noted on explanation needing to be different

Jeanne Boyarsky wrote:Noted on explanation needing to be different

Great. Thanks for the verification!