[swift-evolution] [Pitch] #warning

[Vladimir.S]

 > Furthermore, I believe these tags are merely informational and should
 > not be the reason for using #warnings. Perhaps a comment analysis
 > pointing out where in your project you have tagged comments should
 > suffice. That would also solve the issue of misspelling the tag as
 > FIXME and FIXEM would both show in. And if you don't want to care
 > about FIXME tags at a certain time you could tell the IDE to skip them
 > and FIXEM will surface making you realise you misspelled it.

There is some feature of #warning that could not be covered by tagged 
comments: #warning could be between `#if` .. `#endif` and so could be 
raised depends on condition. Comment is just a comment, I think no tool 
will detect if such comment is in #if..#endif or not. You'll see all tagged 
comments.
I.e. it seems like #warning and tagged comments two separate features.

Again, if I *believe* I really need to raise a user-defined warning in some 
situation, I'll use something like this:

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

and then in code:
TODO(/*My user-defined warning*/)
but I don't think this is the best solution, so I like #warning

On 31.05.2016 19:31, Leonardo Pessoa via swift-evolution wrote:
> In your alternatives considered, you mention "not all TODO or FIXME
> comments should surface" but I think the opposite: if I want these
> types of comments to be seen as warnings by the compiler I cannot
> choose which will surface and which not. It would be the same as
> saying "hey, but I don't want all #warnings to surface or I may have a
> lot in my list" too. Most programming languages work with these "tags"
> (should we call them that?) in comments and offer to show you where
> these are when you want to see them. Perhaps that's what you're saying
> not all of them should surface but if you meant other things that
> should be tagged like this and not surface, you should consider using
> a different tag that will not surface.
>
> Furthermore, I believe these tags are merely informational and should
> not be the reason for using #warnings. Perhaps a comment analysis
> pointing out where in your project you have tagged comments should
> suffice. That would also solve the issue of misspelling the tag as
> FIXME and FIXEM would both show in. And if you don't want to care
> about FIXME tags at a certain time you could tell the IDE to skip them
> and FIXEM will surface making you realise you misspelled it.
>
> L
>
> On 28 May 2016 at 21:55, Robert Widmann via swift-evolution
> <swift-evolution at swift.org> wrote:
>> +1.  This is definitely a useful feature to have and helps advance a clear
>> and common pattern among programmers in general.
>>
>> On May 28, 2016, at 4:58 PM, Harlan Haskins via swift-evolution
>> <swift-evolution at swift.org> wrote:
>>
>> Hey everyone,
>>
>> I’m working on a draft for #warning in Swift. I’ve implemented the draft as
>> it stands, and it’s pretty nice to work with.
>>
>> I’ve pasted it below, and I’d love some feedback! Thanks!
>>
>> — Harlan Haskins
>>
>>
>>
>> #warning
>>
>> Proposal: SE-NNNN
>> Author: Harlan Haskins
>> Status: Awaiting review
>> Review manager: TBD
>>
>> Introduction
>>
>> It's really common for developers to add TODO/FIXME comments in their source
>> code, but there currently isn't a supported facility to make these visible.
>> People have implemented special workarounds to coax Xcode into emitting
>> TODOs and FIXMEs as warnings, but there isn't an accessible way to provide
>> arbitrary warnings, and does not work in a non-Xcode environment.
>>
>> Motivation
>>
>> A #warning is for something you intend to fix before submitting your code or
>> for writing future tasks that you or your teammates intend to complete
>> later. Because this is such a common programming pattern, Swift should have
>> a similar facility.
>>
>> Proposed solution
>>
>> Add #warning(_:) as a new compiler directive that emits a warning diagnostic
>> with the contents, pointing to the start of the message.
>>
>> func configPath() -> String {
>>   #warning("TODO: load this more safely") // expected-warning {{TODO: load
>> this more safely}}
>>   return Bundle.main().path(forResource: "Config", ofType: "plist")!
>> }
>>
>> Detailed design
>>
>> This will add two new productions to the Swift grammar:
>>
>> compiler-control-statement → warning-directive
>> warning-directive → #warning( static-string-literal )
>>
>> Upon parsing this statement, the Swift compiler will immediately emit a
>> warning and discard the statement.
>>
>> If a #warning exists inside a branch of a #if statement that is not taken,
>> then no warning is emitted.
>>
>> #if false
>> #warning(“This won’t exist”)
>> #endif
>>
>> Impact on existing code
>>
>> This change is purely additive; no migration will be required.
>>
>> Alternatives considered
>>
>> We could do some kind of comment-parsing based approach to surface TODOs and
>> FIXMEs, but #warning serves as a general-purpose facility for reporting at
>> compile time. Plus, not all TODO or FIXME comments should surface as
>> warnings in the source.
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>>
>> ~Robert Widmann
>>
>>
>> _______________________________________________
>> 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
>