Thank you Charlie, just exactly what I think regarding all these
#errors/#warnings/comments etc
On 31.05.2016 19:53, Charlie Monroe via swift-evolution wrote:
The way I see it and would use it:
Directives:
*#error* - fatal error, the binary shouldn't compile - e.g. unknown OS host
and the code depends on underlying OS features.
*#warning* - it is a big deal, but allow the binary to compile for testing.
E.g. you know some feature isn't implemented yet and you want a warning so
that you don't forget to implement it before releasing it to the public. Or
as someone has mentioned (I have used #warning like this as well), have a
warning for internal builds so that you don't accidently upload an internal
build to AppStore (happened to me more than once).
Comments:
*TODO* - something that would enhance or improve the app, but the current
behavior is sufficient for release. E.g. "TODO - refactor this code", "TODO
- think of a better name for this function" - it's not fatal, crucial to
the app, but is "nice to have".
*FIXME* - place in code that is known to underperform or fail in certain
situations, but these situations are rather rare and aren't critical. E.g.
"FIXME - when there are 20 000 rows in this table view, it is slow", "FIXME
- when run from a read-only volume, this behaves weirdly".
One may argue that the comment-based markings can be handled by the IDE,
but IMO transferring language features onto IDE is wrong. These comments do
not appear anywhere within the log when the code is compiled.
Comments are IMO "silent/soft" warnings that are good to go through when
you have nothing else to do and look for a way to fix minor issues within
the app. But when you get those mixed with larger issues such as "missing
feature, do not release without it!", you can get a long list and not
notice the important ones on that list. Not to mention you need to
currently search for these manually each time.
Charlie
On May 30, 2016, at 10:57 PM, Christopher Kornher via swift-evolution
<swift-evolution@swift.org <mailto:evolut...@swift.org>> wrote:
On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution
<swift-evolution@swift.org <mailto:evolut...@swift.org>> wrote:
On May 29, 2016, at 10:36 PM, Charlie Monroe <char...@charliemonroe.net
<mailto:char...@charliemonroe.net>> wrote:
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.
The example I've mentioned with #error, doesn't necessarily lead to an
error, but can just issue a #warning("Untested OS, proceed carefully.")
- it IMHO doesn't necessarily be fatal.
This doesn’t make sense to me. If the code is untested, then it should
definitely be audited and check if it is enabled. A #error is the
perfect approach for this case.
I have used warnings in other languages when “bringing-up” large code
bases. Using a #warning facility is helpful at these times. Counting the
messages provides a metric for unresolved questions. I don’t fully
understand Chris’s objection to a warning compiler directive, so I cannot
comment on that. A ‘Mark’ - like comment format would be almost as good.
There is a problem with ‘magic’ comment formats, though. Recently I have
had issues with mistyping “// MARK”. IIRC, “// mark” is not recognized.
Compiler directives do not have this problem. In Objective-C “#pragma
marl" is a compiler error. In swift, “// MARL” is silently treated as a
plain comment.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
