[swift-evolution] /*Let it be*/ func() -> @discardable Bool {} /*Rather Than*/ @discardableResult func() -> Bool {}

Brent Royal-Gordon brent at architechies.com
Wed Oct 18 21:29:40 CDT 2017


> On Oct 9, 2017, at 11:02 PM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> 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

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


More information about the swift-evolution mailing list