#warning isn't exclusively used for FIXMEs. Languages that include these kinds of features do things like flag old modules or unsupported OSes and older Swift versions by combining it with #if - a feature Swift implements far richer conditionals for than other languages I might add. The kinds of developers that are reaching for these features, in addition to TODOs, are the ones that aren't letting their own warnings sit and get stale.
~Robert Widmann 2016/05/28 20:26、Jon Shier via swift-evolution <[email protected]> のメッセージ: > 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 >> 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 > > _______________________________________________ > 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
