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

[Matthew Johnson]

> On May 31, 2016, at 12:35 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Here is the draft proposal: https://github.com/DevAndArtist/swift-evolution/blob/single_expression_optional_return/proposals/nnnn-single-expression-optional-return.md <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.
> 
> 

This is a good start.  

"Make return optional and infer return type for single-expressions everywhere in the language:”

Everywhere in the language is too strong.  We should be more precise.  I believe we are talking about top level code blocks that only contain a single expression for the following constructs in the grammar:

function-body
getter-setter-block
getter-clause 
variable-declaration
subscript-declaration

Please remove the section on guard as any of the preceding will never have single expression top level code blocks if they contain a guard clause.

-Matthew

> 
> 
> 
> -- 
> 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 <mailto: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 <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> >
>> > _______________________________________________
>> > swift-evolution mailing list
>> > swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160531/94e040a8/attachment.html>