[swift-evolution] [Pitch] Make `return` optional in computed properties for a single case
Adrian Zubarev
adrian.zubarev at devandartist.com
Sat May 28 03:37:00 CDT 2016
I'll write a small proposal tomorrow for that behavior (not only for computed properties of course)! Today I'm too busy.
Thank you for your positive feedback.
--
Adrian Zubarev
Sent with Airmail
Am 28. Mai 2016 um 10:11:26, David Hart (david at hartbit.com(mailto:david at hartbit.com)) schrieb:
>
> It isn’t a special case because all other single-statement closures in the language work that way. It’s actually inconsistent now.
>
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160528/9cb56edf/attachment.html>
More information about the swift-evolution
mailing list