Hi Mike,

2017-10-15 14:55 GMT+02:00 Mike Kluev <mike.kl...@gmail.com>:

> On 15 October 2017 at 13:35, Geordie Jay <geo...@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).


>
> my litmus test is: "if we did it now in swift 0.0 what would we do".
> discardable before type passes this test, @discardableResult before
> function doesn't.
>

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.


>
>
>> There has been some discussion of "throws" as a keyword. If anything I
>> think that is something that is in more need of change. I've always read it
>> (frustratingly) as e.g. "func throws Bool", which it doesn't, it throws an
>> Error.
>>
>
> indeed. that's why "throws Bool" is wrong and if anything, i am advocating
> for:
>
> 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*".

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.

- Geordie
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to