[swift-evolution] [Pitch] #warning

[Vladimir.S]

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 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.
>>
>>
>>> -Chris
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>