> 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