[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