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

[Rudolf Adamkovič]

+1

A simple “discardable” would be great. If the result is Bool and “discardable” is placed right in front of it, it’s not only more readable but also eliminates the redundant word “Result”. Also no at sign is great.

Plus, this is super-straightforward to convert for the compiler when upgrading.

R+

Sent from my iPhone

> On 15 Oct 2017, at 15:52, Mike Kluev via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 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
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171015/525c529d/attachment.html>