Based on the feedback from this list, I’ve submitted a revised proposal as PR #353.
https://github.com/apple/swift-evolution/pull/353 Thanks, Harlan > On Jun 1, 2016, at 9:25 PM, Ben Langmuir via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> On May 29, 2016, at 12:58 PM, Erica Sadun <er...@ericasadun.com >>>> <mailto:er...@ericasadun.com>> wrote: >>>> One could make a weak argument that #warning/#error/#message make a nice >>>> family of flexible alerts >>>> just because they're kind of what we're used to already. >>> >>> Right: it isn’t a bad thing at all, but it is certainly the case that >>> people often request adding features to Swift that they see in other >>> languages. Our task is to look at whether the problem is real and >>> significant enough to solve, and if the proposal solves it in the best >>> possible way consistent with the rest of Swift. >>> >>> An similar example is "#pragma mark”. Instead of introducing language >>> support for it, we codified a comment marker (since it is semantically >>> identical to a comment). Xcode picks it up and does the right thing, and I >>> think it has worked out well. >>> >>> As to #warning, Swift’s use of warnings are significant different than the >>> use in C. In C compilers, many of the warnings produced *should* be >>> errors, but can’t be because that effects language conformance and could >>> break a large body of code. Swift doesn’t have this problem, so it treats >>> warnings as “things that should be addressed before you commit your patch, >>> but shouldn’t block a build if (e.g.) you’re in the middle of a big >>> refactoring”. For example, an unused variables is a warning in Swift. >> >> This sounds exactly like what I’d use #warning for. “I’m in the middle of a >> big refactoring, and I haven’t gotten to this part yet; let me put a warning >> in so I can test the other part but won’t forget to come back to it.” It >> might also make sense for doing a series of commits on a branch when you >> need to fix something before merging back to trunk. > > +1 to the proposal, and Jordan has captured my feelings very well here so I > won’t repeat him. > >> >> I think it is important for such diagnostics to show up in compilation, not >> just in IDEs, especially with people using the Swift Package Manager. We >> could have the compiler parse every comment looking for TODOs and FIXMEs by >> default, and emit those as warnings, but I’d want to find out if that >> creates a noticeable difference in parsing time. (It also seems odd that >> comments would be controlled by #if, but maybe that’s silly.) >> >> +1 to the proposal from me, though I agree with Brent that the parentheses >> don’t feel right. This is closer to #if and #setline than #available and >> #selector. >> >> Jordan >> >> P.S. #error is also interesting, but more for “things that should never >> happen” (like the else branch of a platform check), which makes it a bit >> less important. #info/#message can be useful but I’d like to see a concrete >> case before designing it. >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
