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

[Matthew Johnson]

> On May 31, 2016, at 1:16 PM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I really like the proposal in case of properties and functions, but I really don't want to have
> guard boolean else { "false” }

+1.  This is example *is not* a single expression code block.  There are 3 expressions (the condition, the return value in the else block, and the primary return value).

> 
> I feel like `return` is very important part of `guard` statement.
> I understand the requirement for consistency with properties/closures/functions, but I'll prefer to have some inconsistency in language in this case and require `return` for `guard`. And in case I'll have to choose all-or-nothig, I'll give -1 for the proposal.
> 
> I.e. IMO current `return` in properties and functions is less evil than absent of `return` in `guard`.
> 
> On 31.05.2016 20:35, Adrian Zubarev via swift-evolution wrote:
>> Here is the draft proposal:
>> https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/nnnn-single-expression-optional-return.md
>> 
>> Did I covered everything case? If you find some mistakes feel free to
>> provide feedback so I can fix the proposal before I submit a PR.
>> 
>> 
>> 
>> --
>> Adrian Zubarev
>> Sent with Airmail
>> 
>> Am 31. Mai 2016 um 18:33:09, Leonardo Pessoa via swift-evolution
>> (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) schrieb:
>> 
>>> +1
>>> 
>>> L
>>> 
>>> On 31 May 2016 at 12:47, Matthew Johnson via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>> >
>>> >> 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
>>> >
>>> > _______________________________________________
>>> > 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
>> 
>> 
>> 
>> _______________________________________________
>> 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