[swift-evolution] [Pitch] #warning

Vladimir.S svabox at gmail.com
Mon May 30 13:10:55 CDT 2016


1. I don't think we'll lose 'unused value' warning in future, probably 
another warning could be found for this 'feature' that definitely will not 
be dropped.
2. The point was that currently we can 'emulate' user-defined warnings *if 
we really wants*. I believe we need special #warning or #userwarning or 
whatever to emit such warning messages - when we want to be notified until 
we fix this in release code or for other reason.

On 30.05.2016 20:58, Josh Parmenter wrote:
> I think we do, because this solution is not really warning about what we need to warn about. Using an artifact of another warning is something that isn't really solving a problem (if we decide that having proper warning tags is a problem that needs to be solved).
> The warning semantics for let someName and let _ may change later, then you are left with warnings that disappear and are never attended to.
> Best
> Josh
>
> Sent from my iPhone
>
>> On May 30, 2016, at 10:49, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>>
>> Hmm... and like `#warning` :
>>
>> let TODO_WeNeedToMakeItFaster  = "Current implementation is too slow, use xxxx" // some comments that you need to show
>>
>> and we have a warning(unused value)! from compiler! with
>>
>> WARNING at line 8, col 7: initialization of immutable value 'TODO_WeNeedToMakeItFaster' was never used; consider replacing with assignment to '_' or removing it
>>  let TODO_WeNeedToMakeItFaster  = "Current implementation is too slow, use xxxx" // some comments that you need to show
>>  ~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> PROFIT :)
>>
>> So.. don't we need normal solution ?
>>
>>> On 30.05.2016 20:33, Michael Peternell wrote:
>>> Something similar to #error seems to be already implemented ;)
>>>
>>> #if os(iOS)
>>>    import Error_sorryThisDoesntWorkOnIOSyet
>>> #endif
>>>
>>> I know it's a hack, but it works :) And the good thing is, there is no way to prevent these kind of hacks.. (but IMHO, #error would look nicer)
>>>
>>> -Michael
>>>
>>>> Am 30.05.2016 um 17:49 schrieb Vladimir.S via swift-evolution <swift-evolution at swift.org>:
>>>>
>>>> I also think that we need standardized feature for todo/fixme in language, so when you got one's code you can have all needed warnings the creator wants to produce.
>>>> I.e. probably not some directive, but some kind of.. special comment? So XCode/any 3rd party tools/IDE will know about this standardized format and produce/show user-created 'warnings' instead of compiler(as core team against such warnings in compiler)
>>>>
>>>>> On 30.05.2016 18:28, Shawn Erickson via swift-evolution wrote:
>>>>>
>>>>> On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution
>>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>
>>>>>   Tools like SonarQube can raise a "warning" for comments started with
>>>>>   "TODO:" or "FIXME:". Wouldn't it be more interesting if those could be
>>>>>   presented as warnings instead of using #warning? And this could be an
>>>>>   optional setting as commented would not influence compilation.
>>>>>
>>>>>
>>>>> It seems wise to me to have the concept of todo, fixme, etc. formalized in
>>>>> the language so that source kit, the swift compiler, and things like Xcode
>>>>> would have a well defined thing to look for and extract information from.
>>>>>
>>>>> I support this proposal and hope it can cover these typical use cases.
>>>>>
>>>>> -Shawn
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>


More information about the swift-evolution mailing list