[swift-evolution] Make non-void functions @warn_unused_result by default

Paul Ossenbruggen possen at gmail.com
Thu Feb 25 00:37:16 CST 2016


Also this is not without precedent and feels more swift like to me.  In switch cases you can include or drop the let or the var. 

for example;

switch coord {
case (let x, _): print(x)
case (_, let y); print(y)
case let (x, y): print(x,y)
}

underscore does not need the keyword let here.


> On Feb 24, 2016, at 9:59 PM, Paul Ossenbruggen <possen at gmail.com> wrote:
> 
> Since we don’t care about the result?
> 
> _ = ignoreResult()
> 
> It does not matter whether it is mutable or not so dropping the keyword is ok here. This is really obvious what it does and is concise. 
>  
> 
>> On Feb 24, 2016, at 9:54 PM, Charles Kissinger <crk at akkyra.com <mailto:crk at akkyra.com>> wrote:
>> 
>> 
>>> On Feb 24, 2016, at 9:19 PM, Paul Ossenbruggen <possen at gmail.com <mailto:possen at gmail.com>> wrote:
>>> 
>>> These lack conciseness. What about the already supported: 
>>> 
>>> let _ = ingoreResult()
>> 
>> I would be perfectly happy with requiring “let _ = “ myself. My recollection of the previous discussion is that most people didn’t want that to be necessary and preferred a suppressible warning.
>> 
>> Thinking about the attribute name some more, I might prefer:
>> 
>> @NoUnusedResultWarning
>> 
>> which is a variation of one of Erica’s suggestions. It is at least slightly shorter than @SuppressUnusedResultWarning
>> 
>> —CK
>> 
>>> 
>>> Where ignoreResult is the function. Or maybe something even more brief? What was wrong with (void)? or 
>>> 
>>> 	(_)ingoreResult()
>>> 
>>> - Paul 
>>> 
>>> 
>>>> On Feb 24, 2016, at 8:42 PM, Charles Kissinger via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> 
>>>>> On Feb 24, 2016, at 7:12 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> I'd rather have something clear than short.
>>>>> 
>>>>> Some short ones that haven't been mentioned:
>>>>> @Statement has a problem because the result can be used, it's just not mandated. 
>>>>> @Statementable just makes no English sense at all (similarly @Procedurable) but kind of communicates the idea
>>>>> @ResultDiscardable: not a fan
>>>>> @StatementAllowed or @AllowStatement really doesn't make a ton of sense, but it's short and kind of gets the point across.
>>>>> @SideEffects also short, also kind hints at stuff, also could be misleading, and the same for @HasSideEffects.
>>>>> My favorite remains @SuppressUnusedResultWarning, which isn't short but pretty damn clear.
>>>> 
>>>> +1. This would be my choice as well. It is the warning that is affected, not the result, so “Warning” or “NoWarn” should be in the name.
>>>> 
>>>> —CK
>>>> 
>>>>>  
>>>>> 
>>>>>> On Feb 24, 2016, at 7:32 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> 
>>>>>>> @optional_result (or ideally @optionalResult if camel-case for attributes is accepted) is clearer I think if we want a shortened two-word form.
>>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160224/d046587b/attachment-0001.html>


More information about the swift-evolution mailing list