> 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
