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

[Adrian Zubarev]

Given that Swift 3 is winding down, we are in a mode of declining PRs for proposals that don’t align with its goals. Please bring this back up for discussion this fall, thanks for understanding.
Closed by Chris. Sad but we’ll have to wait a little longer for this change.



-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juni 2016 um 06:58:27, Thorsten Seitz (tseitz42 at icloud.com) schrieb:

+1  

`return` in guards should stay, because there one has to use either `return`, `continue` or `break`. It would be ugly and inconsistent if one of these could be left out.  

-Thorsten  

> Am 31.05.2016 um 20:16 schrieb Vladimir.S via swift-evolution <swift-evolution at swift.org>:  
>  
> I really like the proposal in case of properties and functions, but I really don't want to have  
> guard boolean else { "false" }  
>  
> 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  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160601/d940f4a7/attachment.html>