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.
-Chris
···
On May 29, 2016, at 10:36 PM, Charlie Monroe <charlie@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.
One could make a weak argument that warning/error/#message make a nice family of flexible alerts
just because they're kind of what we're used to already.
Right: it isn’t a bad thing at all, but it is certainly the case that people often request adding features to Swift that they see in other languages. Our task is to look at whether the problem is real and significant enough to solve, and if the proposal solves it in the best possible way consistent with the rest of Swift.
An similar example is "#pragma mark”. Instead of introducing language support for it, we codified a comment marker (since it is semantically identical to a comment). Xcode picks it up and does the right thing, and I think it has worked out well.
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. Swift doesn’t have this problem, so it treats warnings as “things that should be addressed before you commit your patch, but shouldn’t block a build if (e.g.) you’re in the middle of a big refactoring”. For example, an unused variables is a warning in Swift.
This sounds exactly like what I’d use warning for. “I’m in the middle of a big refactoring, and I haven’t gotten to this part yet; let me put a warning in so I can test the other part but won’t forget to come back to it.” It might also make sense for doing a series of commits on a branch when you need to fix something before merging back to trunk.
+1 to the proposal, and Jordan has captured my feelings very well here so I won’t repeat him.
···
On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
On May 29, 2016, at 13:20, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 29, 2016, at 12:58 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
I think it is important for such diagnostics to show up in compilation, not just in IDEs, especially with people using the Swift Package Manager. We could have the compiler parse every comment looking for TODOs and FIXMEs by default, and emit those as warnings, but I’d want to find out if that creates a noticeable difference in parsing time. (It also seems odd that comments would be controlled by if, but maybe that’s silly.)
+1 to the proposal from me, though I agree with Brent that the parentheses don’t feel right. This is closer to if and #setline than #available and selector.
Jordan
P.S. error is also interesting, but more for “things that should never happen” (like the else branch of a platform check), which makes it a bit less important. #info/#message can be useful but I’d like to see a concrete case before designing it.
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.
···
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 <charlie@charliemonroe.net> wrote:
It seems wise to me to have the concept of todo, fixme, etc. formalized in
the language so that source kit, the swift compiler, and things like Xcode
would have a well defined thing to look for and extract information from.
I support this proposal and hope it can cover these typical use cases.
-Shawn
···
On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution < swift-evolution@swift.org> wrote:
Tools like SonarQube can raise a "warning" for comments started with
"TODO:" or "FIXME:". Wouldn't it be more interesting if those could be
presented as warnings instead of using warning? And this could be an
optional setting as commented would not influence compilation.
Based on the feedback from this list, I’ve submitted a revised proposal as PR #353.
Thanks,
Harlan
···
On Jun 1, 2016, at 9:25 PM, Ben Langmuir via swift-evolution <swift-evolution@swift.org> wrote:
On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 29, 2016, at 13:20, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 29, 2016, at 12:58 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
One could make a weak argument that warning/error/#message make a nice family of flexible alerts
just because they're kind of what we're used to already.
Right: it isn’t a bad thing at all, but it is certainly the case that people often request adding features to Swift that they see in other languages. Our task is to look at whether the problem is real and significant enough to solve, and if the proposal solves it in the best possible way consistent with the rest of Swift.
An similar example is "#pragma mark”. Instead of introducing language support for it, we codified a comment marker (since it is semantically identical to a comment). Xcode picks it up and does the right thing, and I think it has worked out well.
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. Swift doesn’t have this problem, so it treats warnings as “things that should be addressed before you commit your patch, but shouldn’t block a build if (e.g.) you’re in the middle of a big refactoring”. For example, an unused variables is a warning in Swift.
This sounds exactly like what I’d use warning for. “I’m in the middle of a big refactoring, and I haven’t gotten to this part yet; let me put a warning in so I can test the other part but won’t forget to come back to it.” It might also make sense for doing a series of commits on a branch when you need to fix something before merging back to trunk.
+1 to the proposal, and Jordan has captured my feelings very well here so I won’t repeat him.
I think it is important for such diagnostics to show up in compilation, not just in IDEs, especially with people using the Swift Package Manager. We could have the compiler parse every comment looking for TODOs and FIXMEs by default, and emit those as warnings, but I’d want to find out if that creates a noticeable difference in parsing time. (It also seems odd that comments would be controlled by if, but maybe that’s silly.)
+1 to the proposal from me, though I agree with Brent that the parentheses don’t feel right. This is closer to if and #setline than #available and selector.
Jordan
P.S. error is also interesting, but more for “things that should never happen” (like the else branch of a platform check), which makes it a bit less important. #info/#message can be useful but I’d like to see a concrete case before designing it.
I also think that we need standardized feature for todo/fixme in language, so when you got one's code you can have all needed warnings the creator wants to produce.
I.e. probably not some directive, but some kind of.. special comment? So XCode/any 3rd party tools/IDE will know about this standardized format and produce/show user-created 'warnings' instead of compiler(as core team against such warnings in compiler)
···
On 30.05.2016 18:28, Shawn Erickson via swift-evolution wrote:
On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Tools like SonarQube can raise a "warning" for comments started with
"TODO:" or "FIXME:". Wouldn't it be more interesting if those could be
presented as warnings instead of using warning? And this could be an
optional setting as commented would not influence compilation.
It seems wise to me to have the concept of todo, fixme, etc. formalized in
the language so that source kit, the swift compiler, and things like Xcode
would have a well defined thing to look for and extract information from.
I support this proposal and hope it can cover these typical use cases.
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 <charlie@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.
Something similar to error seems to be already implemented ;)
if os(iOS)
import Error_sorryThisDoesntWorkOnIOSyet #endif
I know it's a hack, but it works :) And the good thing is, there is no way to prevent these kind of hacks.. (but IMHO, error would look nicer)
-Michael
···
Am 30.05.2016 um 17:49 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org>:
I also think that we need standardized feature for todo/fixme in language, so when you got one's code you can have all needed warnings the creator wants to produce.
I.e. probably not some directive, but some kind of.. special comment? So XCode/any 3rd party tools/IDE will know about this standardized format and produce/show user-created 'warnings' instead of compiler(as core team against such warnings in compiler)
On 30.05.2016 18:28, Shawn Erickson via swift-evolution wrote:
On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Tools like SonarQube can raise a "warning" for comments started with
"TODO:" or "FIXME:". Wouldn't it be more interesting if those could be
presented as warnings instead of using warning? And this could be an
optional setting as commented would not influence compilation.
It seems wise to me to have the concept of todo, fixme, etc. formalized in
the language so that source kit, the swift compiler, and things like Xcode
would have a well defined thing to look for and extract information from.
I support this proposal and hope it can cover these typical use cases.
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@swift.org <mailto:evolution@swift.org>> wrote:
On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution >>> <swift-evolution@swift.org <mailto:evolution@swift.org>> wrote:
On May 29, 2016, at 10:36 PM, Charlie Monroe <charlie@charliemonroe.net >>>> <mailto:charlie@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.
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.
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.
···
On 31 May 2016, at 18:53, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:
let TODO_WeNeedToMakeItFaster = "Current implementation is too slow, use xxxx" // some comments that you need to show
and we have a warning(unused value)! from compiler! with
WARNING at line 8, col 7: initialization of immutable value 'TODO_WeNeedToMakeItFaster' was never used; consider replacing with assignment to '_' or removing it
let TODO_WeNeedToMakeItFaster = "Current implementation is too slow, use xxxx" // some comments that you need to show
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
PROFIT :)
So.. don't we need normal solution ?
···
On 30.05.2016 20:33, Michael Peternell wrote:
Something similar to error seems to be already implemented ;)
if os(iOS)
import Error_sorryThisDoesntWorkOnIOSyet #endif
I know it's a hack, but it works :) And the good thing is, there is no way to prevent these kind of hacks.. (but IMHO, error would look nicer)
-Michael
Am 30.05.2016 um 17:49 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org>:
I also think that we need standardized feature for todo/fixme in language, so when you got one's code you can have all needed warnings the creator wants to produce.
I.e. probably not some directive, but some kind of.. special comment? So XCode/any 3rd party tools/IDE will know about this standardized format and produce/show user-created 'warnings' instead of compiler(as core team against such warnings in compiler)
On 30.05.2016 18:28, Shawn Erickson via swift-evolution wrote:
On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Tools like SonarQube can raise a "warning" for comments started with
"TODO:" or "FIXME:". Wouldn't it be more interesting if those could be
presented as warnings instead of using warning? And this could be an
optional setting as commented would not influence compilation.
It seems wise to me to have the concept of todo, fixme, etc. formalized in
the language so that source kit, the swift compiler, and things like Xcode
would have a well defined thing to look for and extract information from.
I support this proposal and hope it can cover these typical use cases.
You realize that both Clang and Swift parses structured doc comments? Comments are an important part of the language, just like any other syntax.
-Chris
···
On Jun 1, 2016, at 3:56 AM, Jeremy Pereira via swift-evolution <swift-evolution@swift.org> wrote:
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.
I think we do, because this solution is not really warning about what we need to warn about. Using an artifact of another warning is something that isn't really solving a problem (if we decide that having proper warning tags is a problem that needs to be solved).
The warning semantics for let someName and let _ may change later, then you are left with warnings that disappear and are never attended to.
Best
Josh
···
Sent from my iPhone
On May 30, 2016, at 10:49, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
Hmm... and like `#warning` :
let TODO_WeNeedToMakeItFaster = "Current implementation is too slow, use xxxx" // some comments that you need to show
and we have a warning(unused value)! from compiler! with
WARNING at line 8, col 7: initialization of immutable value 'TODO_WeNeedToMakeItFaster' was never used; consider replacing with assignment to '_' or removing it
let TODO_WeNeedToMakeItFaster = "Current implementation is too slow, use xxxx" // some comments that you need to show
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
PROFIT :)
So.. don't we need normal solution ?
On 30.05.2016 20:33, Michael Peternell wrote:
Something similar to error seems to be already implemented ;)
if os(iOS)
import Error_sorryThisDoesntWorkOnIOSyet #endif
I know it's a hack, but it works :) And the good thing is, there is no way to prevent these kind of hacks.. (but IMHO, error would look nicer)
-Michael
Am 30.05.2016 um 17:49 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org>:
I also think that we need standardized feature for todo/fixme in language, so when you got one's code you can have all needed warnings the creator wants to produce.
I.e. probably not some directive, but some kind of.. special comment? So XCode/any 3rd party tools/IDE will know about this standardized format and produce/show user-created 'warnings' instead of compiler(as core team against such warnings in compiler)
On 30.05.2016 18:28, Shawn Erickson via swift-evolution wrote:
On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Tools like SonarQube can raise a "warning" for comments started with
"TODO:" or "FIXME:". Wouldn't it be more interesting if those could be
presented as warnings instead of using warning? And this could be an
optional setting as commented would not influence compilation.
It seems wise to me to have the concept of todo, fixme, etc. formalized in
the language so that source kit, the swift compiler, and things like Xcode
would have a well defined thing to look for and extract information from.
I support this proposal and hope it can cover these typical use cases.
1. I don't think we'll lose 'unused value' warning in future, probably another warning could be found for this 'feature' that definitely will not be dropped.
2. The point was that currently we can 'emulate' user-defined warnings *if we really wants*. I believe we need special warning or #userwarning or whatever to emit such warning messages - when we want to be notified until we fix this in release code or for other reason.
···
On 30.05.2016 20:58, Josh Parmenter wrote:
I think we do, because this solution is not really warning about what we need to warn about. Using an artifact of another warning is something that isn't really solving a problem (if we decide that having proper warning tags is a problem that needs to be solved).
The warning semantics for let someName and let _ may change later, then you are left with warnings that disappear and are never attended to.
Best
Josh
Sent from my iPhone
On May 30, 2016, at 10:49, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
Hmm... and like `#warning` :
let TODO_WeNeedToMakeItFaster = "Current implementation is too slow, use xxxx" // some comments that you need to show
and we have a warning(unused value)! from compiler! with
WARNING at line 8, col 7: initialization of immutable value 'TODO_WeNeedToMakeItFaster' was never used; consider replacing with assignment to '_' or removing it
let TODO_WeNeedToMakeItFaster = "Current implementation is too slow, use xxxx" // some comments that you need to show
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
PROFIT :)
So.. don't we need normal solution ?
On 30.05.2016 20:33, Michael Peternell wrote:
Something similar to error seems to be already implemented ;)
if os(iOS)
import Error_sorryThisDoesntWorkOnIOSyet #endif
I know it's a hack, but it works :) And the good thing is, there is no way to prevent these kind of hacks.. (but IMHO, error would look nicer)
-Michael
Am 30.05.2016 um 17:49 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org>:
I also think that we need standardized feature for todo/fixme in language, so when you got one's code you can have all needed warnings the creator wants to produce.
I.e. probably not some directive, but some kind of.. special comment? So XCode/any 3rd party tools/IDE will know about this standardized format and produce/show user-created 'warnings' instead of compiler(as core team against such warnings in compiler)
On 30.05.2016 18:28, Shawn Erickson via swift-evolution wrote:
On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Tools like SonarQube can raise a "warning" for comments started with
"TODO:" or "FIXME:". Wouldn't it be more interesting if those could be
presented as warnings instead of using warning? And this could be an
optional setting as commented would not influence compilation.
It seems wise to me to have the concept of todo, fixme, etc. formalized in
the language so that source kit, the swift compiler, and things like Xcode
would have a well defined thing to look for and extract information from.
I support this proposal and hope it can cover these typical use cases.
WARNING at line 12, col 3: result of call to 'TODO()' is unused
TODO(/*Make it faster*/) // any comment you want
we have a user-defined warning + no initialization of any const + almost no overhead even for release code.
···
On 30.05.2016 20:58, Josh Parmenter wrote:
I think we do, because this solution is not really warning about what we need to warn about. Using an artifact of another warning is something that isn't really solving a problem (if we decide that having proper warning tags is a problem that needs to be solved).
The warning semantics for let someName and let _ may change later, then you are left with warnings that disappear and are never attended to.
Best
Josh
Sent from my iPhone
On May 30, 2016, at 10:49, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:
Hmm... and like `#warning` :
let TODO_WeNeedToMakeItFaster = "Current implementation is too slow, use xxxx" // some comments that you need to show
and we have a warning(unused value)! from compiler! with
WARNING at line 8, col 7: initialization of immutable value 'TODO_WeNeedToMakeItFaster' was never used; consider replacing with assignment to '_' or removing it
let TODO_WeNeedToMakeItFaster = "Current implementation is too slow, use xxxx" // some comments that you need to show
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~
PROFIT :)
So.. don't we need normal solution ?
On 30.05.2016 20:33, Michael Peternell wrote:
Something similar to error seems to be already implemented ;)
if os(iOS)
import Error_sorryThisDoesntWorkOnIOSyet #endif
I know it's a hack, but it works :) And the good thing is, there is no way to prevent these kind of hacks.. (but IMHO, error would look nicer)
-Michael
Am 30.05.2016 um 17:49 schrieb Vladimir.S via swift-evolution <swift-evolution@swift.org>:
I also think that we need standardized feature for todo/fixme in language, so when you got one's code you can have all needed warnings the creator wants to produce.
I.e. probably not some directive, but some kind of.. special comment? So XCode/any 3rd party tools/IDE will know about this standardized format and produce/show user-created 'warnings' instead of compiler(as core team against such warnings in compiler)
On 30.05.2016 18:28, Shawn Erickson via swift-evolution wrote:
On Sun, May 29, 2016 at 3:49 PM Leonardo Pessoa via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Tools like SonarQube can raise a "warning" for comments started with
"TODO:" or "FIXME:". Wouldn't it be more interesting if those could be
presented as warnings instead of using warning? And this could be an
optional setting as commented would not influence compilation.
It seems wise to me to have the concept of todo, fixme, etc. formalized in
the language so that source kit, the swift compiler, and things like Xcode
would have a well defined thing to look for and extract information from.
I support this proposal and hope it can cover these typical use cases.
+1 The usefulness of these directives depends upon a number of factors, including the nature of the project, and the maturity of the project. These directives will be very handy for my workflow in early stage development and integration. These are common in other languages, so they should not be foreign to the vast majority of developers.
Adding an #info or #message would require changes to tooling that recognizes errors and warnings from compilers in order to surface this output to users. More importantly, I have never seen an informational message from a compiler and such messages see to be at odds with the common design pattern that compilers only emit output for problems.
Proposal nitpick: you call these "directives" in the grammar but "statements" in the text. This is important for the word "ignore" and particularly for something like this:
switch foo {
// We can put comments before the first case,
// but not statements or declarations. Is this okay?
#warning "hello"
case 1:
break
#if os(macOS)
// We can also put comments between #if and a case,
// but if we put a statement or declaration then we don't
// have consistent structure. Is this okay?
#warning "goodbye"
case 2:
break
#endif
default:
break
}
I know this is a long-lived thread, but was wondering if I could chime in with the possibility of adding a "#comment" directive, to be treated as simple cout lines with no ramifications to the build.
The justification for something like this is that I have many projects where I have test code, hard-coded values to get past certain parts for debugging other parts, and I just want to make sure that I remember when doing builds that they're there.
I'd be willing to take a crack at adding it if it seems useful and not redundant to existing functionality.