I appreciate the sentiment, but I think we should reserve warnings for actual compiler diagnostics. If you wish to add another, user definable diagnostic type, like official compiler support for a #todo or #fixme flag, then go ahead. But adding #warning because the IDE (read Xcode) doesn’t automatically pick up FIXMEs or TODOs isn’t a compelling enough reason. In addition, enabling developers to add their own warnings which can then just be ignored just encourages the very bad habit of ignoring warnings in general. Perhaps this could be something for libIDE, rather than the core language?
Jon Shier > On May 28, 2016, at 7: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 > <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md> > Author: Harlan Haskins <https://github.com/harlanhaskins> > Status: Awaiting review > <https://gist.github.com/harlanhaskins/bfe2d56d7655c5bfdb1855eaf00addb4#rationale> > Review manager: TBD > > <https://gist.github.com/harlanhaskins/bfe2d56d7655c5bfdb1855eaf00addb4#introduction>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 > <https://bendodson.com/weblog/2014/10/02/showing-todo-as-warning-in-swift-xcode-project/> > 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. > > > <https://gist.github.com/harlanhaskins/bfe2d56d7655c5bfdb1855eaf00addb4#motivation>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. > > > <https://gist.github.com/harlanhaskins/bfe2d56d7655c5bfdb1855eaf00addb4#proposed-solution>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")! > } > > <https://gist.github.com/harlanhaskins/bfe2d56d7655c5bfdb1855eaf00addb4#detailed-design>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 > > <https://gist.github.com/harlanhaskins/bfe2d56d7655c5bfdb1855eaf00addb4#impact-on-existing-code>Impact > on existing code > > This change is purely additive; no migration will be required. > > > <https://gist.github.com/harlanhaskins/bfe2d56d7655c5bfdb1855eaf00addb4#alternatives-considered>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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
