> On 31 May 2016, at 18:53, Charlie Monroe via swift-evolution
> <[email protected]> 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.
Something that is inside a comment is not a language feature by definition.
Upthread, somebody posted a link to this script
TAGS="TODO:|FIXME:"
echo "searching ${SRCROOT} for ${TAGS}"
find "${SRCROOT}" \( -name "*.swift" \) -print0 | xargs -0 egrep
--with-filename --line-number --only-matching "($TAGS).*\$" | perl -p -e
"s/($TAGS)/ warning: \$1/“
which works like a charm with Xcode as a run script build phase and can easily
be adapted to any build system where running a shell script is possible.
It’s also easily extensible. If we add compiler support for certain patterns of
comments, then many other patterns that projects might like to use are
unavailable e.g. I’ve seen // XXX: Fix me!
So I would be against the compiler parsing comments for TODOs and FIXMEs.
However, I do recognise that frequently such things do not necessarily merit
flagging as a warning but would benefit from some compiler support, so why not
introduce an extra level of compiler output message that is lower than a
warning. Don’t know what I would call it, I’d probably take a leaf out of the
syslog book.
e.g.
#error This source code is not supported on your platform
#warning I haven’t validated that this force unwrapped variable really is not
nil
#info This is where we’ll call frobnicate once the phalange grommet feature is
added.
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
