[swift-evolution] [Pitch] Make `return` optional in computed properties for a single case

[Matthew Johnson]

> On May 28, 2016, at 3:09 AM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.

Computed properties aren’t closures so it’s not inconsistent in that sense.  But it is inconsistent in that closures are the *only* value-returning code blocks that are able to use this sugar.  It would be nice to see this sugar consistently allowed everywhere in the language.

> 
>> On 28 May 2016, at 09:03, Brian Christensen via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> On May 27, 2016, at 13:57, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> The idea is simple:
>>> 
>>> 	• Can we make return keyword optional in cases like this?
>>> 	• Shouldn’t this behave like @autoclosure or @noescape?
>>> type A {
>>>   var characters: [Character] = …
>>>   var string: String { String(self.characters) }
>>>   var count: Int { 42 }
>>> }
>>> 
>>> Is this worth a proposal or Swifty enough, what do you think?
>>> 
>>> Sure I could write return, but why do we allow this behavior for @noescape functions like map!?
>> 
>> While I am not necessarily against this idea, I do wonder if it’s worth making what’s going on here less obvious simply for the sake of being able to omit a six character keyword. As I understand it, one of the reasons ++/-- were removed was due to the increased "burden to learn Swift as a first programming language.” This is the sort of thing that becomes another one of those special cases that has to be explained to someone new to Swift.
>> 
>> /brian
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution