Re: [swift-evolution] [Pitch] #warning

[Harlan Haskins via swift-evolution]

Based on the feedback from this list, I’ve submitted a revised proposal as PR 
#353.

https://github.com/apple/swift-evolution/pull/353

Thanks,
Harlan

> On Jun 1, 2016, at 9:25 PM, Ben Langmuir via swift-evolution 
>  wrote:
> 
>> 
>> On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>>> 
>>> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
 On May 29, 2016, at 12:58 PM, Erica Sadun > 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.
>> 
>> 
>> ___
>> 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 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Ben Langmuir via swift-evolution]

> On Jun 1, 2016, at 10:54 AM, Jordan Rose via swift-evolution 
>  wrote:
> 
>> 
>> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution 
>> > wrote:
>> 
>>> On May 29, 2016, at 12:58 PM, Erica Sadun >> > 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.
> 
> 
> ___
> 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

Re: [swift-evolution] [Pitch] #warning

[Chris Lattner via swift-evolution]

On Jun 1, 2016, at 3:56 AM, Jeremy Pereira via swift-evolution 
 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. 

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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Jordan Rose via swift-evolution]

> On May 29, 2016, at 13:20, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On May 29, 2016, at 12:58 PM, Erica Sadun  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.

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.


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Jeremy Pereira via swift-evolution]

> On 31 May 2016, at 18: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.


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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Vladimir.S via swift-evolution]

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
> wrote:



On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution
> wrote:



On May 29, 2016, at 10:36 PM, Charlie Monroe > 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




___
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

Re: [swift-evolution] [Pitch] #warning

[Gwendal Roué via swift-evolution]

> Le 31 mai 2016 à 18:31, Leonardo Pessoa via swift-evolution 
>  a écrit :
> 
> In your alternatives considered, you mention "not all TODO or FIXME
> comments should surface" but I think the opposite

Well, use #warning TODO, then. The proposal works well with several coding 
habits, including yours. This is good.

Gwendal Roué

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Leonardo Pessoa via swift-evolution]

In your alternatives considered, you mention "not all TODO or FIXME
comments should surface" but I think the opposite: if I want these
types of comments to be seen as warnings by the compiler I cannot
choose which will surface and which not. It would be the same as
saying "hey, but I don't want all #warnings to surface or I may have a
lot in my list" too. Most programming languages work with these "tags"
(should we call them that?) in comments and offer to show you where
these are when you want to see them. Perhaps that's what you're saying
not all of them should surface but if you meant other things that
should be tagged like this and not surface, you should consider using
a different tag that will not surface.

Furthermore, I believe these tags are merely informational and should
not be the reason for using #warnings. Perhaps a comment analysis
pointing out where in your project you have tagged comments should
suffice. That would also solve the issue of misspelling the tag as
FIXME and FIXEM would both show in. And if you don't want to care
about FIXME tags at a certain time you could tell the IDE to skip them
and FIXEM will surface making you realise you misspelled it.

L

On 28 May 2016 at 21:55, Robert Widmann via swift-evolution
 wrote:
> +1.  This is definitely a useful feature to have and helps advance a clear
> and common pattern among programmers in general.
>
> On May 28, 2016, at 4:58 PM, Harlan Haskins via swift-evolution
>  wrote:
>
> Hey everyone,
>
> I’m working on a draft for #warning in Swift. I’ve implemented the draft as
> it stands, and it’s pretty nice to work with.
>
> I’ve pasted it below, and I’d love some feedback! Thanks!
>
> — Harlan Haskins
>
>
>
> #warning
>
> Proposal: SE-
> Author: Harlan Haskins
> Status: Awaiting review
> Review manager: TBD
>
> Introduction
>
> It's really common for developers to add TODO/FIXME comments in their source
> code, but there currently isn't a supported facility to make these visible.
> People have implemented special workarounds to coax Xcode into emitting
> TODOs and FIXMEs as warnings, but there isn't an accessible way to provide
> arbitrary warnings, and does not work in a non-Xcode environment.
>
> Motivation
>
> A #warning is for something you intend to fix before submitting your code or
> for writing future tasks that you or your teammates intend to complete
> later. Because this is such a common programming pattern, Swift should have
> a similar facility.
>
> Proposed solution
>
> Add #warning(_:) as a new compiler directive that emits a warning diagnostic
> with the contents, pointing to the start of the message.
>
> func configPath() -> String {
>   #warning("TODO: load this more safely") // expected-warning {{TODO: load
> this more safely}}
>   return Bundle.main().path(forResource: "Config", ofType: "plist")!
> }
>
> Detailed design
>
> This will add two new productions to the Swift grammar:
>
> compiler-control-statement → warning-directive
> warning-directive → #warning( static-string-literal )
>
> Upon parsing this statement, the Swift compiler will immediately emit a
> warning and discard the statement.
>
> If a #warning exists inside a branch of a #if statement that is not taken,
> then no warning is emitted.
>
> #if false
> #warning(“This won’t exist”)
> #endif
>
> Impact on existing code
>
> This change is purely additive; no migration will be required.
>
> Alternatives considered
>
> We could do some kind of comment-parsing based approach to surface TODOs and
> FIXMEs, but #warning serves as a general-purpose facility for reporting at
> compile time. Plus, not all TODO or FIXME comments should surface as
> warnings in the source.
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
> ~Robert Widmann
>
>
> ___
> 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

Re: [swift-evolution] [Pitch] #warning

[Christopher Kornher via swift-evolution]

> On May 30, 2016, at 2:35 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 29, 2016, at 10:36 PM, Charlie Monroe  
>> 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

Re: [swift-evolution] [Pitch] #warning

[Robert Widmann via swift-evolution]

+1.  This is definitely a useful feature to have and helps advance a clear and 
common pattern among programmers in general.

> On May 28, 2016, at 4:58 PM, Harlan Haskins via swift-evolution 
> > wrote:
> 
> Hey everyone,
> 
> I’m working on a draft for #warning in Swift. I’ve implemented the draft as 
> it stands, and it’s pretty nice to work with.
> 
> I’ve pasted it below, and I’d love some feedback! Thanks!
> 
> — Harlan Haskins
> 
> 
> 
> #warning
> 
> Proposal: SE- 
> 
> Author: Harlan Haskins 
> Status: Awaiting review 
> 
> Review manager: TBD
>  
> Introduction
> 
> It's really common for developers to add TODO/FIXME comments in their source 
> code, but there currently isn't a supported facility to make these visible. 
> People have implemented special workarounds 
> 
>  to coax Xcode into emitting TODOs and FIXMEs as warnings, but there isn't an 
> accessible way to provide arbitrary warnings, and does not work in a 
> non-Xcode environment.
> 
>  
> Motivation
> 
> A #warning is for something you intend to fix before submitting your code or 
> for writing future tasks that you or your teammates intend to complete later. 
> Because this is such a common programming pattern, Swift should have a 
> similar facility.
> 
>  
> Proposed
>  solution
> 
> Add #warning(_:) as a new compiler directive that emits a warning diagnostic 
> with the contents, pointing to the start of the message.
> 
> func configPath() -> String {
>   #warning("TODO: load this more safely") // expected-warning {{TODO: load 
> this more safely}}
>   return Bundle.main().path(forResource: "Config", ofType: "plist")!
> }
>  
> Detailed
>  design
> 
> This will add two new productions to the Swift grammar:
> 
> compiler-control-statement → warning-directive
> warning-directive → #warning( static-string-literal )
> Upon parsing this statement, the Swift compiler will immediately emit a 
> warning and discard the statement.
> 
> If a #warning exists inside a branch of a #if statement that is not taken, 
> then no warning is emitted.
> 
> #if false
> #warning(“This won’t exist”)
> #endif
>  
> Impact
>  on existing code
> 
> This change is purely additive; no migration will be required.
> 
>  
> Alternatives
>  considered
> 
> We could do some kind of comment-parsing based approach to surface TODOs and 
> FIXMEs, but #warning serves as a general-purpose facility for reporting at 
> compile time. Plus, not all TODO or FIXME comments should surface as warnings 
> in the source.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 



~Robert Widmann

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Vladimir.S via swift-evolution]

Btw, FWIW, regarding the state that some warning semantics can change later..

@warn_unused_result
func TODO()->Bool {return true}

Then in code:

TODO(/*Make it faster*/) // any comment you want

Will have:

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 
 wrote:

Hmm... and like `#warning` :

let TODO_WeNeedToMakeItFaster  = "Current implementation is too slow, use " 
// 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 
" // 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 
:

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
> 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.

-Shawn


___
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

___
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

Re: [swift-evolution] [Pitch] #warning

[Chris Lattner via swift-evolution]

> On May 29, 2016, at 10:36 PM, Charlie Monroe  
> 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.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Vladimir.S via swift-evolution]

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 
 wrote:

Hmm... and like `#warning` :

let TODO_WeNeedToMakeItFaster  = "Current implementation is too slow, use " 
// 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 
" // 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 
:

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
> 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.

-Shawn


___
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

___
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

Re: [swift-evolution] [Pitch] #warning

[Vladimir.S via swift-evolution]

Hmm... and like `#warning` :

let TODO_WeNeedToMakeItFaster  = "Current implementation is too slow, use 
" // 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 " // 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 
:

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
> 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.

-Shawn


___
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




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Michael Peternell via swift-evolution]

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 
> :
> 
> 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
>> > 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.
>> 
>> -Shawn
>> 
>> 
>> ___
>> 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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Vladimir.S via swift-evolution]

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
> 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.

-Shawn


___
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

Re: [swift-evolution] [Pitch] #warning

[Shawn Erickson via swift-evolution]

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.
>

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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Callionica (Swift) via swift-evolution]

I've used custom warnings and errors in other languages and find them both
useful.

Forgive my ignorance, but does Swift have warning levels, warning IDs and
pragmas/build settings to disable specific warnings? If so, it would be
good to specify exactly how this feature interact with those.

For example, when viewing compiler messages produced by #warning/#error I
would expect there to be an indication (separate from the message produced)
that tells me what warning or error this is (in other words, an ID). The ID
is useful not just for humans reading or writing tools to parse build logs,
but also for connecting to external documentation describing the
warning/error in more detail, and for selectively disabling particular
warnings. If Swift has IDs for warnings and errors (surely?) then this
feature should too.

-- Callionica
​
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Charlie Monroe via swift-evolution]

> 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.

My issue with this being handled by Xcode (and generally with any feature 
discussed here that someone suggests it should be handled by Xcode) is that 
Xcode is the least customizable IDE I've ever seen and from what I've talked to 
some Xcode developers via bugreport.apple.com, they are not very keen on adding 
any customization features. But sadly I haven't found a better IDE.

Yes, I admit, I have abused #warning in the past (ObjC/C) to make sure I don't 
forget to implement something before shipping the product (usually during 
refactoring, so that I don't forget to come back and finish refactoring 
something). And with Swift, I have made TODO comments and of course, I've 
forgotten about a few places. It makes you search for TODO or FIXME all the 
time. The jump bar is way too hidden and not visible, a developer can't be 
expected to open each file and go through the jump bar for each file...

So a solution for this would be for Xcode to provide an option to issue 
warnings for TODOs and FIXMEs - and we're back to warnings.

Charlie
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Harlan Haskins via swift-evolution]

FWIW, I'm also in favor of adding #error to the language. It would be good to 
express invariants that the compiler can't know about, like mutually exclusive 
build config options that affect code downstream.

I'm definitely seeing how #warning might conflict with the goals of Swift's 
warnings.

If there's interest, I would be willing to transform this into a #error 
proposal.

- Harlan

On May 29, 2016, at 1:20 PM, Chris Lattner via swift-evolution 
 wrote:

>> On May 29, 2016, at 12:58 PM, Erica Sadun  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 difference in policy is what makes me question where #warning makes 
> sense for Swift.  OTOH, errors in Swift are used in exactly the same way as 
> in C compilers, which is why bringing #error forward makes sense to me.
> 
> -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

Re: [swift-evolution] [Pitch] #warning

[Leonardo Pessoa via swift-evolution]

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.



-Original Message-
From: "Will Stanton via swift-evolution" <swift-evolution@swift.org>
Sent: ‎29/‎05/‎2016 07:09 PM
To: "Harlan Haskins" <har...@harlanhaskins.com>
Cc: "swift-evolution" <swift-evolution@swift.org>
Subject: Re: [swift-evolution] [Pitch] #warning

+1 to #warning or optionally(?) emitting something like TODO: more visibly!

In past ObjC projects, I have used #warning to confirm the right macros were 
enabled.

I often (1) work around differences between the iOS simulator and device with 
TARGET_IPHONE_SIMULATOR (+similar) and (2) change API endpoints among sandbox, 
production, etc… (which may not relate to whether the open project is 
debug/release)
For instance, I have code like:
#if TARGET_IPHONE_SIMULATOR || API_DEBUG
[Declarations]
#warning DEBUG API: Do not release
#else
[Different declarations]
#endif

I check that release builds do not emit a “warning Do not release” before 
submitting/deploying.


I think it would be great if (1) lines/branches of Swift source with #warning 
or something like INDICATE: are highlighted and (2) FIXMEs, TODOs, warnings, 
etc… are emitted and put into the Issues Navigator of Xcode.

In the past, both of the above (line highlighting and the ease of checking the 
Issues Navigator for “warning: Do not release” in Xcode) were conducive to my 
sanity:
Issue highlighting from the last build seems more reliable than syntax 
highlighting. Xcode syntax highlighting colors (1) sometimes goes down (I’ve 
encountered SourceKit crashes pretty often) or (2) is wrong (perhaps macros 
weren’t detected correctly).
Also, while (3) using schemes and (4) seeing the -Doptions in the build command 
are useful, they are less visible by themselves.

Regards,
Will Stanton

> On May 29, 2016, at 4:20 PM, Chris Lattner via swift-evolution 
> <swift-evolution@swift.org> 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. 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 difference in policy is what makes me question where #warning makes 
> sense for Swift.  OTOH, errors in Swift are used in exactly the same way as 
> in C compilers, which is why bringing #error forward makes sense to me.

___
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

Re: [swift-evolution] [Pitch] #warning

[Will Stanton via swift-evolution]

+1 to #warning or optionally(?) emitting something like TODO: more visibly!

In past ObjC projects, I have used #warning to confirm the right macros were 
enabled.

I often (1) work around differences between the iOS simulator and device with 
TARGET_IPHONE_SIMULATOR (+similar) and (2) change API endpoints among sandbox, 
production, etc… (which may not relate to whether the open project is 
debug/release)
For instance, I have code like:
#if TARGET_IPHONE_SIMULATOR || API_DEBUG
[Declarations]
#warning DEBUG API: Do not release
#else
[Different declarations]
#endif

I check that release builds do not emit a “warning Do not release” before 
submitting/deploying.


I think it would be great if (1) lines/branches of Swift source with #warning 
or something like INDICATE: are highlighted and (2) FIXMEs, TODOs, warnings, 
etc… are emitted and put into the Issues Navigator of Xcode.

In the past, both of the above (line highlighting and the ease of checking the 
Issues Navigator for “warning: Do not release” in Xcode) were conducive to my 
sanity:
Issue highlighting from the last build seems more reliable than syntax 
highlighting. Xcode syntax highlighting colors (1) sometimes goes down (I’ve 
encountered SourceKit crashes pretty often) or (2) is wrong (perhaps macros 
weren’t detected correctly).
Also, while (3) using schemes and (4) seeing the -Doptions in the build command 
are useful, they are less visible by themselves.

Regards,
Will Stanton

> On May 29, 2016, at 4:20 PM, Chris Lattner via swift-evolution 
>  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. 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 difference in policy is what makes me question where #warning makes 
> sense for Swift.  OTOH, errors in Swift are used in exactly the same way as 
> in C compilers, which is why bringing #error forward makes sense to me.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Chris Lattner via swift-evolution]

> On May 29, 2016, at 12:58 PM, Erica Sadun  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 difference in policy is what makes me question where #warning makes sense 
for Swift.  OTOH, errors in Swift are used in exactly the same way as in C 
compilers, which is why bringing #error forward makes sense to me.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Erica Sadun via swift-evolution]

> On May 29, 2016, at 1:44 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> 
>> On May 28, 2016, at 8:26 PM, Jon Shier via swift-evolution 
>>  wrote:
>> 
>>  I appreciate the sentiment, but I think we should reserve warnings for 
>> actual compiler diagnostics.
> 
> +1.  The IDE should just pick up "// FIXME: “ comments and summarize them as 
> issues.  Xcode already shows them in its jump bar.
> 
> That said, I can see a use for #error, as Charlie shows downthread:
> 
> #if os(OSX)
>   /// ...
> #if os(Linux)
>   /// ...
> #else
>   #error("This OS isn't supported yet.").
> #endif
> 
> -Chris

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. A possible use case 
for warning:

#if canImport(Cocoa)
#warning("Your UI will look bad. This code works under OS X but this 
library is intended for iOS-like environments")
#elseif !canImport(UIKit)
#error("Unsupported target GUI")
#endif

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Chris Lattner via swift-evolution]

> On May 28, 2016, at 8:26 PM, Jon Shier via swift-evolution 
>  wrote:
> 
>   I appreciate the sentiment, but I think we should reserve warnings for 
> actual compiler diagnostics.

+1.  The IDE should just pick up "// FIXME: “ comments and summarize them as 
issues.  Xcode already shows them in its jump bar.

That said, I can see a use for #error, as Charlie shows downthread:

#if os(OSX)
/// ...
#if os(Linux)
/// ...
#else
#error("This OS isn't supported yet.").
#endif

-Chris
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Robert Widmann via swift-evolution]

#warning isn't exclusively used for FIXMEs.  Languages that include these kinds 
of features do things like flag old modules or unsupported OSes and older Swift 
versions by combining it with #if - a feature Swift implements far richer 
conditionals for than other languages I might add.  The kinds of developers 
that are reaching for these features, in addition to TODOs, are the ones that 
aren't letting their own warnings sit and get stale.

~Robert Widmann

2016/05/28 20:26、Jon Shier via swift-evolution  
のメッセージ:

>   I appreciate the sentiment, but I think we should reserve warnings for 
> actual compiler diagnostics. If you wish to add another, user definable 
> diagnostic type, like official compiler support for a #todo or #fixme flag, 
> then go ahead. But adding #warning because the IDE (read Xcode) doesn’t 
> automatically pick up FIXMEs or TODOs isn’t a compelling enough reason. In 
> addition, enabling developers to add their own warnings which can then just 
> be ignored just encourages the very bad habit of ignoring warnings in 
> general. Perhaps this could be something for libIDE, rather than the core 
> language?
> 
> 
> 
> Jon Shier
> 
>> On May 28, 2016, at 7:58 PM, Harlan Haskins via swift-evolution 
>>  wrote:
>> 
>> Hey everyone,
>> 
>> I’m working on a draft for #warning in Swift. I’ve implemented the draft as 
>> it stands, and it’s pretty nice to work with.
>> 
>> I’ve pasted it below, and I’d love some feedback! Thanks!
>> 
>> ― Harlan Haskins
>> 
>> 
>> 
>> #warning
>> Proposal: SE-
>> Author: Harlan Haskins
>> Status: Awaiting review
>> Review manager: TBD
>> Introduction
>> 
>> It's really common for developers to add TODO/FIXME comments in their source 
>> code, but there currently isn't a supported facility to make these visible. 
>> People have implemented special workarounds to coax Xcode into emitting 
>> TODOs and FIXMEs as warnings, but there isn't an accessible way to provide 
>> arbitrary warnings, and does not work in a non-Xcode environment.
>> 
>> Motivation
>> 
>> A #warning is for something you intend to fix before submitting your code or 
>> for writing future tasks that you or your teammates intend to complete 
>> later. Because this is such a common programming pattern, Swift should have 
>> a similar facility.
>> 
>> Proposed solution
>> 
>> Add #warning(_:) as a new compiler directive that emits a warning diagnostic 
>> with the contents, pointing to the start of the message.
>> 
>> func configPath() -> String {
>>   #warning("TODO: load this more safely") // expected-warning {{TODO: load 
>> this more safely}}
>>   return Bundle.main().path(forResource: "Config", ofType: "plist")!
>> }
>> Detailed design
>> 
>> This will add two new productions to the Swift grammar:
>> 
>> compiler-control-statement → warning-directive
>> warning-directive → #warning( static-string-literal )
>> Upon parsing this statement, the Swift compiler will immediately emit a 
>> warning and discard the statement.
>> 
>> If a #warning exists inside a branch of a #if statement that is not taken, 
>> then no warning is emitted.
>> 
>> #if false
>> #warning(“This won’t exist”)
>> #endif
>> Impact on existing code
>> 
>> This change is purely additive; no migration will be required.
>> 
>> Alternatives considered
>> 
>> We could do some kind of comment-parsing based approach to surface TODOs and 
>> FIXMEs, but #warning serves as a general-purpose facility for reporting at 
>> compile time. Plus, not all TODO or FIXME comments should surface as 
>> warnings in the source.
>> 
>> ___
>> 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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] #warning

[Harlan Haskins via swift-evolution]

I can see where you're coming from, but I don't necessarily see this as 
"warnings which can then be ignored." In my vision, this enables developers to 
increase visibility of known issues, instead of letting them sit. Developers 
who would normally use this feature to add their own warnings are likely not 
the developers who will then turn around and ignore warnings.

- Harlan

> On May 28, 2016, at 8:26 PM, Jon Shier  wrote:
> 
>   I appreciate the sentiment, but I think we should reserve warnings for 
> actual compiler diagnostics. If you wish to add another, user definable 
> diagnostic type, like official compiler support for a #todo or #fixme flag, 
> then go ahead. But adding #warning because the IDE (read Xcode) doesn’t 
> automatically pick up FIXMEs or TODOs isn’t a compelling enough reason. In 
> addition, enabling developers to add their own warnings which can then just 
> be ignored just encourages the very bad habit of ignoring warnings in 
> general. Perhaps this could be something for libIDE, rather than the core 
> language?
> 
> 
> 
> Jon Shier
> 
>> On May 28, 2016, at 7:58 PM, Harlan Haskins via swift-evolution 
>>  wrote:
>> 
>> Hey everyone,
>> 
>> I’m working on a draft for #warning in Swift. I’ve implemented the draft as 
>> it stands, and it’s pretty nice to work with.
>> 
>> I’ve pasted it below, and I’d love some feedback! Thanks!
>> 
>> — Harlan Haskins
>> 
>> 
>> 
>> #warning
>> Proposal: SE-
>> Author: Harlan Haskins
>> Status: Awaiting review
>> Review manager: TBD
>> Introduction
>> 
>> It's really common for developers to add TODO/FIXME comments in their source 
>> code, but there currently isn't a supported facility to make these visible. 
>> People have implemented special workarounds to coax Xcode into emitting 
>> TODOs and FIXMEs as warnings, but there isn't an accessible way to provide 
>> arbitrary warnings, and does not work in a non-Xcode environment.
>> 
>> Motivation
>> 
>> A #warning is for something you intend to fix before submitting your code or 
>> for writing future tasks that you or your teammates intend to complete 
>> later. Because this is such a common programming pattern, Swift should have 
>> a similar facility.
>> 
>> Proposed solution
>> 
>> Add #warning(_:) as a new compiler directive that emits a warning diagnostic 
>> with the contents, pointing to the start of the message.
>> 
>> func configPath() -> String {
>>   #warning("TODO: load this more safely") // expected-warning {{TODO: load 
>> this more safely}}
>>   return Bundle.main().path(forResource: "Config", ofType: "plist")!
>> }
>> Detailed design
>> 
>> This will add two new productions to the Swift grammar:
>> 
>> compiler-control-statement → warning-directive
>> warning-directive → #warning( static-string-literal )
>> Upon parsing this statement, the Swift compiler will immediately emit a 
>> warning and discard the statement.
>> 
>> If a #warning exists inside a branch of a #if statement that is not taken, 
>> then no warning is emitted.
>> 
>> #if false
>> #warning(“This won’t exist”)
>> #endif
>> Impact on existing code
>> 
>> This change is purely additive; no migration will be required.
>> 
>> Alternatives considered
>> 
>> We could do some kind of comment-parsing based approach to surface TODOs and 
>> FIXMEs, but #warning serves as a general-purpose facility for reporting at 
>> compile time. Plus, not all TODO or FIXME comments should surface as 
>> warnings in the source.
>> 
>> ___
>> 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

Re: [swift-evolution] [Pitch] #warning

[Jon Shier via swift-evolution]

I appreciate the sentiment, but I think we should reserve warnings for 
actual compiler diagnostics. If you wish to add another, user definable 
diagnostic type, like official compiler support for a #todo or #fixme flag, 
then go ahead. But adding #warning because the IDE (read Xcode) doesn’t 
automatically pick up FIXMEs or TODOs isn’t a compelling enough reason. In 
addition, enabling developers to add their own warnings which can then just be 
ignored just encourages the very bad habit of ignoring warnings in general. 
Perhaps this could be something for libIDE, rather than the core language?



Jon Shier

> On May 28, 2016, at 7:58 PM, Harlan Haskins via swift-evolution 
>  wrote:
> 
> Hey everyone,
> 
> I’m working on a draft for #warning in Swift. I’ve implemented the draft as 
> it stands, and it’s pretty nice to work with.
> 
> I’ve pasted it below, and I’d love some feedback! Thanks!
> 
> — Harlan Haskins
> 
> 
> 
> #warning
> 
> Proposal: SE- 
> 
> Author: Harlan Haskins 
> Status: Awaiting review 
> 
> Review manager: TBD
>  
> Introduction
> 
> It's really common for developers to add TODO/FIXME comments in their source 
> code, but there currently isn't a supported facility to make these visible. 
> People have implemented special workarounds 
> 
>  to coax Xcode into emitting TODOs and FIXMEs as warnings, but there isn't an 
> accessible way to provide arbitrary warnings, and does not work in a 
> non-Xcode environment.
> 
>  
> Motivation
> 
> A #warning is for something you intend to fix before submitting your code or 
> for writing future tasks that you or your teammates intend to complete later. 
> Because this is such a common programming pattern, Swift should have a 
> similar facility.
> 
>  
> Proposed
>  solution
> 
> Add #warning(_:) as a new compiler directive that emits a warning diagnostic 
> with the contents, pointing to the start of the message.
> 
> func configPath() -> String {
>   #warning("TODO: load this more safely") // expected-warning {{TODO: load 
> this more safely}}
>   return Bundle.main().path(forResource: "Config", ofType: "plist")!
> }
>  
> Detailed
>  design
> 
> This will add two new productions to the Swift grammar:
> 
> compiler-control-statement → warning-directive
> warning-directive → #warning( static-string-literal )
> Upon parsing this statement, the Swift compiler will immediately emit a 
> warning and discard the statement.
> 
> If a #warning exists inside a branch of a #if statement that is not taken, 
> then no warning is emitted.
> 
> #if false
> #warning(“This won’t exist”)
> #endif
>  
> Impact
>  on existing code
> 
> This change is purely additive; no migration will be required.
> 
>  
> Alternatives
>  considered
> 
> We could do some kind of comment-parsing based approach to surface TODOs and 
> FIXMEs, but #warning serves as a general-purpose facility for reporting at 
> compile time. Plus, not all TODO or FIXME comments should surface as warnings 
> in the source.
> 
> ___
> 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

[swift-evolution] [Pitch] #warning

[Harlan Haskins via swift-evolution]

Hey everyone,

I’m working on a draft for #warning in Swift. I’ve implemented the draft as it 
stands, and it’s pretty nice to work with.

I’ve pasted it below, and I’d love some feedback! Thanks!

— Harlan Haskins



#warning

Proposal: SE- 

Author: Harlan Haskins 
Status: Awaiting review 

Review manager: TBD
 
Introduction

It's really common for developers to add TODO/FIXME comments in their source 
code, but there currently isn't a supported facility to make these visible. 
People have implemented special workarounds 

 to coax Xcode into emitting TODOs and FIXMEs as warnings, but there isn't an 
accessible way to provide arbitrary warnings, and does not work in a non-Xcode 
environment.

 
Motivation

A #warning is for something you intend to fix before submitting your code or 
for writing future tasks that you or your teammates intend to complete later. 
Because this is such a common programming pattern, Swift should have a similar 
facility.

 
Proposed
 solution

Add #warning(_:) as a new compiler directive that emits a warning diagnostic 
with the contents, pointing to the start of the message.

func configPath() -> String {
  #warning("TODO: load this more safely") // expected-warning {{TODO: load this 
more safely}}
  return Bundle.main().path(forResource: "Config", ofType: "plist")!
}
 
Detailed
 design

This will add two new productions to the Swift grammar:

compiler-control-statement → warning-directive
warning-directive → #warning( static-string-literal )
Upon parsing this statement, the Swift compiler will immediately emit a warning 
and discard the statement.

If a #warning exists inside a branch of a #if statement that is not taken, then 
no warning is emitted.

#if false
#warning(“This won’t exist”)
#endif
 
Impact
 on existing code

This change is purely additive; no migration will be required.

 
Alternatives
 considered

We could do some kind of comment-parsing based approach to surface TODOs and 
FIXMEs, but #warning serves as a general-purpose facility for reporting at 
compile time. Plus, not all TODO or FIXME comments should surface as warnings 
in the source.

smime.p7s
Description: S/MIME cryptographic signature
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution