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

Mike Kluev mike.kluev at gmail.com
Sun Oct 15 08:52:29 CDT 2017

On 15 October 2017 at 14:23, Geordie Jay <geojay at gmail.com> wrote:

> Hi Mike,
> 2017-10-15 14:55 GMT+02:00 Mike Kluev <mike.kluev at gmail.com>:
>> On 15 October 2017 at 13:35, Geordie Jay <geojay at gmail.com> wrote:
>>> Also we're not talking about whether the Bool itself is discardable. For
>>> example, it makes no sense to write:
>>> *let something: discardable Bool = true*
>> you can't write this either:
>> let something: inout Bool = true
>> that doesn't mean "inout" should be "@inputOutput" before the parameter
>> name in function signature.
> This is a different case: inout is an annotation on argument types (of
> which there can be many).

i mean:

@discardableResult func foo(@inputOutput x: Int, @inputOutput y: Float) ->


func goo(x: inout Int, y: inout y) -> discardable Bool

i deliberately mixed the current @discardableResult syntax with a
hypothetical "consistent" @inputOutput syntax to make my point more clear.
to me these use cases are virtually the same, and syntax shall be
consistent among them.

> I don't understand what you're saying here. "Now in swift 0.0"? The first
> public version of Swift had this same functionality in its same form, with
> the name @warn_unused_result. The current version is just reversed, which
> to me is a logical change.

in other words: "if we didn't have swift already what would I do" kind of
test. similar to the one that we already officially use: "if it wasn't done
already, would we do it now" to prune rarely used language constructs.

remember the evolution of the "inout" keyword:

(inout x: Int)  --->  "var parameters dropped" + (x: inout Int)

similarly, it's not unimaginable to consider this evolution as well:

"@warn_unused_result func" --> "@discardableResult func" --> "func foo() ->
discardable Bool"

> throwing func foo() -> Bool
> I personally like that syntax, because that's exactly how I *talk* about
> such a function. "oh that's a throwing function so you need to call it with
> *try*".

you are the first who +1-ed it so far, so we now have +2 in total for

> As an extension to that, I'd also say "you can call that function without
> a preceding variable assignment because it has a discardable result". I
> would never say "this function returns a discardable boolean" because that
> just doesn't match my mental model of what's going on. To me, it's the
> *function* whose return value can be discarded — in theory it has nothing
> to do with the result itself. But it's quite possible I'm in the minority
> here.

to me it's trivial:

func foo() -> Bool    - means "function foo returning result of type Bool"


func foo() -> discardable Bool    - means "function foo returning result of
type Bool that can be unused by the caller"

very compatible with:

foo(x: inout Bool)    - means input / output parameter x that is of type

if you don't complain about the latter (like: "how come Bool is input
output?! it is the parameter that is input / output, not the Bool itself
!!!" or, similarly: "how come the function returns type Never? the function
just never returns but the type shall be Void !!!") then I don't see why
you don't accept the former.

But it's quite possible I'm in the minority here.

as a matter of fact, so far it looks I am :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171015/788e2ae3/attachment.html>

More information about the swift-evolution mailing list