[swift-evolution] [Pitch] #warning

Vladimir.S svabox at gmail.com
Mon May 30 15:43:03 CDT 2016


Btw, FWIW, regarding the state that some warning semantics can change later..

@warn_unused_result
func TODO()->Bool {return true}

Then in code:

TODO(/*Make it faster*/) // any comment you want

Will have:

WARNING at line 12, col 3: result of call to 'TODO()' is unused
   TODO(/*Make it faster*/) // any comment you want

we have a user-defined warning + no initialization of any const + almost no 
overhead even for release code.

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