[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