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> wrote:
>
>
>> On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>>
>>> On May 29, 2016, at 10:36 PM, Charlie Monroe <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
>> 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
