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

[Mike Kluev]

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) ->
Bool

vs:

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
"throwing".


> 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"

ditto:

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
Bool

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 :)

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