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

Wed Jun 1 16:41:07 CDT 2016

I imagine you can use a combination of:

*Deferred for Future Discussion*:
    https://github.com/apple/swift-evolution#deferred-for-future-discussion

*Accepted proposals which do not have a complete implementation:*

https://github.com/apple/swift-evolution#accepted-proposals-which-do-not-have-a-complete-implementation
*Pull requests:*
    https://github.com/apple/swift-evolution/pulls

On Thu, Jun 2, 2016 at 3:25 AM, Adrian Zubarev via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
> >
>
>
> _______________________________________________
> 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/20160602/488b0346/attachment.html>