> On 31 Jan 2017, at 09:07, Alex Hoppen via swift-evolution
> <[email protected]> wrote:
>
> This was a deliberate change between Swift 3 beta 1 and beta 2 after a friend
> of mine pointed the following inconsistency out to me:
>
> struct Foo {
> func bar() {}
> }
> let foo: Foo? = Foo()
> foo?.bar() // Does not create a warning
> true ? foo?.bar() : foo?.bar() // expression of type '()?' is unused
>
> After some offline discussion at WWDC with the Swift team we decided to move
> to a consistent model where ()?, ()??, … is always discardable since we
> didn't want to take the convenience of foo?.bar() away (something that
> regularly occurs with weak variables, e.g. captures in closures).
>
> So much for the history of this feature.
Thanks for clarifying, but this is an interesting case actually; it seems the
problem here is the ternary, as presumably the following would have worked just
fine:
if true { foo?.bar() }
else { foo?.bar() }
So your example's problem seems to stem then from the fact that the ternary's
type isn't inheriting the discardable nature of the two branches. I wonder then
if an alternative solution might to have discardable be an inheritable
property, while keeping optional chaining implicitly discardable?
For example:
@discardableResult func foo() -> Int { return 1 }
func bar() -> Int { return 2 }
struct Baz { func baz() {}}
let a:Baz? = Baz()
true ? foo() : bar() // type is Int, should produce a warning
true ? foo() : foo() // type is discardable Int, no warning necessary
true ? a?.baz() : a?.baz() // type is discardable Void, no warning necessary
The idea basically being that @discardableResult becomes a property of return
types that is passed for as long as it is in common, but does not prevent two
types (one discardable, one not) from being equal.
This might give a best of both? As method chaining producing implicitly
discardable results would allow your example to behave as expected, but other
cases can still be configured as desired with @discardableResult (or not)._______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
