> 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
<[email protected]> 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
<[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
~Robert Widmann
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
