> On Oct 9, 2017, at 11:02 PM, Xiaodi Wu via swift-evolution 
> <[email protected]> wrote:
> 
> This idea was discussed long ago and the present design was selected.

But this design was discussed in the proposal as a "future direction", because 
@discardableResult was chosen partially because it was easier to implement. It 
says so [in the proposal][1]. This is why we write formal proposals, Xiaodi—so 
we remember why we made the decisions we made.

        * * *

Now, the proposal specifically suggests we delay `@discardable` "until such 
time as there's a strong motivation to use such an approach". Do we have such a 
motivation?

I actually think we do (although it may not be strong enough). Currently, we 
have two types—`Void` (as well as optionals, of any depth, wrapping `Void`) and 
`Never`—which are "implicitly discardable". That is, you don't need to mark a 
function which returns those types with `@discardableResult`; it inherently is. 
This is currently handled with [an ad-hoc test][2], but I think we should 
consider strengthening and opening up this mechanism.

Why? Because there are other types we would like to be implicitly discardable. 
You can already make an argument for types like `Array<Void>`, but concurrency 
will bring types like `Future<Void>` which could get pretty strong benefits 
from it. Since we're planning to leave a lot of async stuff to userspace, there 
ought to be a userspace way to mark types as implicitly discardable. And if 
discardability stems from the type system, it's pretty natural to make ad-hoc 
discardibility a property attached to the type, too.

(We could then mark `Never` with @discardable, make tuples discardable unless 
one of their elements is not discardable, make optionals discardable if the 
type they wrap is discardable, and—et voilà!—we have a nice, general language 
feature with as little magic as we can manage.)

        [1]: 
https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md#future-directions
        [2]: 
https://github.com/apple/swift/blob/e907031d3d4555e917ca3ad7fffeac7f580331a0/lib/Sema/TypeCheckStmt.cpp#L991

-- 
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to