[swift-evolution] ternary operator ?: suggestion
Alex Lew
alexl.mail+swift at gmail.com
Sat Dec 5 18:28:10 CST 2015
I don't think you can just get rid of the if statement in favor of an
expression. You still want to be able to do this:
if (condition) {
funcWithSideEffectsThatReturnsInt()
} else {
funcWithSideEffectsThatReturnsString()
}
but that's not a valid expression (what is its type?).
On Sat, Dec 5, 2015 at 7:24 PM, Ole Begemann via swift-evolution <
swift-evolution at swift.org> wrote:
> Yeah, returning an optional is a good idea.
>
> > On 06 Dec 2015, at 01:22, Adam C. Lickel <adam at lickel.com> wrote:
> >
> > In that situation, the if statement could return a Void? where the else
> implicitly returns nil
> >
> >> On Dec 5, 2015, at 3:12 PM, Ole Begemann via swift-evolution <
> swift-evolution at swift.org> wrote:
> >>
> >>>> This is subtle and requires thought
> >>>
> >>> What do you envision as the pitfalls of the design thinking behind
> if/switch expressions? I’m not a compiler programmer, but a prog-lang
> enthusiast. I wouldn’t mind a little nudge in the right direction.
> >>
> >> One thing that comes to mind is that if "if" is an expression, every if
> needs an else branch. This makes it harder to use if to conditionally
> perform side effects. For example, this is currently valid:
> >>
> >> func doSomething() { ... }
> >>
> >> if condition {
> >> doSomething()
> >> }
> >>
> >> Should this be allowed? You could argue that this should work because
> (a) the expression result is unused and (b) the return type of doSomething
> is Void, so the compiler could conceivably implicitly construct an else
> branch that returns (). But it would be inconsistent with other
> expressions. Disallowing this style could make writing typical "imperative"
> code harder.
> >>
> >> – Ole
> _______________________________________________
> 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/20151205/6787eefc/attachment.html>
More information about the swift-evolution
mailing list