[swift-evolution] [Pitch] #warning
svabox at gmail.com
Tue May 31 13:18:09 CDT 2016
Thank you Charlie, just exactly what I think regarding all these
On 31.05.2016 19:53, Charlie Monroe via swift-evolution wrote:
> The way I see it and would use it:
> *#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).
> *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.
>> On May 30, 2016, at 10:57 PM, Christopher Kornher via swift-evolution
>> <swift-evolution at swift.org <mailto:evolution at swift.org>> wrote:
>>> On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution
>>> <swift-evolution at swift.org <mailto:evolution at swift.org>> wrote:
>>>> On May 29, 2016, at 10:36 PM, Charlie Monroe <charlie at charliemonroe.net
>>>> <mailto:charlie at 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.
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution