Proposal: single-expression method bodies

[Brian Goetz]

It’s not been discussed *here*, but its certainly been discussed.  (IIRC, C# has supported this for a while.)

Personally, I like this feature, for all the reasons you suggest, and more (symmetry, elimination of low-value repetition, encouragement of single-expression methods).  We’ve got our plates pretty full right now, but rest assured this is on the list to carefully consider as a candidate.  
 

> On Nov 23, 2017, at 2:24 AM, Zheka Kozlov <orionllmain at gmail.com> wrote:
> 
> Sorry if I'm repeating what was already discussed before. I didn't find
> anything about this in the old threads.
> 
> Currently, lambdas support two forms of bodies:
> 
> 1. Function<Integer, String> func = (Integer i) -> i.toString();
> 2. Function<Integer, String> func = (Integer i) -> {
>    return i.toString();
> };
> 
> But for methods only the second form is supported:
> 
> public String func(Integer i) {
>    return i.toString();
> }
> 
> This seems unfair to me, and I think the first form should be supported too:
> 
> public String func(Integer i) -> i.toString()
> 
> 
> Single-expression method bodies can reduce the amount of boilerplate:
> 
> public static int square(int x) -> x * x
> 
> // Simple getter
> public int getSomeField() -> someField;
> 
> 
> This will also be consistent with the two forms of switch (regular switch
> and expression switch):
> 
> switch (o) {
>    case Integer i: return i.toString();
> }
> 
> vs.
> 
> String s = switch (o) {
>    case Integer i -> i.toString();
> }
> 
> What do you think?