[swift-evolution] [Idea] return if / return unless

[Julian Dunskus]

I don’t agree with that. To me, everything between return and if (including the return itself) only being executed if the condition is true seems like the logical way of interpreting that syntax.

I do, however, see how people skimming through code might be confused, but a return with code after it should make it obvious that there’s more to it than always returning at that point.

> On 05 Aug 2016, at 04:58, rintaro ishizaki <fs.output at gmail.com> wrote:
> 
> Limiting for `return` introduces another problem.
> 
> mutating func increment() -> Val {
>   self = self.incremented()
>   return self
> }
> 
> return val.increment() if val == sentinel
> print(val)
> 
> I think, it's not obvious `val` after `return ... if` is incremented or not.
> 
> 
> 2016-08-05 9:11 GMT+09:00 Julian Dunskus via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
> On 05 Aug 2016, at 01:24, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
> >
> >> On Aug 4, 2016, at 6:38 AM, Julian Dunskus via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> >>
> >> return nil unless let thing = things[index]
> >
> > On the `unless` part, at least, see the "Rename guard to unless" section in Commonly Rejected Changes: <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>>
> >
> 
> I read that, see paragraph three of the email you replied to (my second in this thread)
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160805/e836230c/attachment.html>