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

Adrian Zubarev adrian.zubarev at devandartist.com
Wed Jun 1 12:25:54 CDT 2016


Feel free to convince the core team to add such a list. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 1. Juni 2016 um 19:17:25, Vladimir.S (svabox at gmail.com) schrieb:

Do we have any 'feature' to not just throw away of proposals(and then scan  
mail list and remember), but put them in queue of proposals that should be  
reviewed after Swift 3 is released?  

Probably some list of such proposals on site, don't know. So I believe any  
proposal that would be raised now and got support from community - should  
be added to that queue on some page somewhere on swift.org  

On 01.06.2016 20:03, Adrian Zubarev via swift-evolution wrote:  
> 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  
> <mailto: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  
>  
>  
>  
> _______________________________________________  
> 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/6fac031c/attachment.html>


More information about the swift-evolution mailing list