[Pitch] #warning

harlanhaskins · May 28, 2016, 11:58pm

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-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author: Harlan Haskins <https://github.com/harlanhaskins>
Status: Awaiting review <se-0000-pound-warning.md · GitHub;
Review manager: TBD
<se-0000-pound-warning.md · GitHub

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 <https://bendodson.com/weblog/2014/10/02/showing-todo-as-warning-in-swift-xcode-project/> 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.

<se-0000-pound-warning.md · GitHub

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.

<se-0000-pound-warning.md · GitHub 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")!
}
<se-0000-pound-warning.md · GitHub 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
<se-0000-pound-warning.md · GitHub on existing code

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

<se-0000-pound-warning.md · GitHub 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.

Beta · May 29, 2016, 12:55am

+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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author: Harlan Haskins <https://github.com/harlanhaskins>
Status: Awaiting review <se-0000-pound-warning.md · GitHub;
Review manager: TBD
<se-0000-pound-warning.md · GitHub

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 <https://bendodson.com/weblog/2014/10/02/showing-todo-as-warning-in-swift-xcode-project/> 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.

<se-0000-pound-warning.md · GitHub

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.

<se-0000-pound-warning.md · GitHub 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")!
}
<se-0000-pound-warning.md · GitHub 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
<se-0000-pound-warning.md · GitHub on existing code

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

<se-0000-pound-warning.md · GitHub 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

~Robert Widmann

Jon_Shier · May 29, 2016, 3:26am

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 <swift-evolution@swift.org> 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-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author: Harlan Haskins <https://github.com/harlanhaskins>
Status: Awaiting review <se-0000-pound-warning.md · GitHub;
Review manager: TBD
<se-0000-pound-warning.md · GitHub

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 <https://bendodson.com/weblog/2014/10/02/showing-todo-as-warning-in-swift-xcode-project/> 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.

<se-0000-pound-warning.md · GitHub

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.

<se-0000-pound-warning.md · GitHub 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")!
}
<se-0000-pound-warning.md · GitHub 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
<se-0000-pound-warning.md · GitHub on existing code

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

<se-0000-pound-warning.md · GitHub 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

harlanhaskins · May 29, 2016, 4:25am

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 <jon@jonshier.com> 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 <swift-evolution@swift.org> 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-NNNN
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

codafi · May 29, 2016, 4:36am

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 <swift-evolution@swift.org> のメッセージ:

···

  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 <swift-evolution@swift.org> 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-NNNN
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

Charlie_Monroe1 · May 29, 2016, 7:33am

+1 - this is a useful feature in C-like languages. I'd prefer adding error as well - you can have a file that depends on the OS features and may want to have a branch of the if statements ending in

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

···

On May 29, 2016, at 6:36 AM, Robert Widmann via swift-evolution <swift-evolution@swift.org> wrote:

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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> のメッセージ:

  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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
Author: Harlan Haskins <https://github.com/harlanhaskins>
Status: Awaiting review <se-0000-pound-warning.md · GitHub;
Review manager: TBD
<se-0000-pound-warning.md · GitHub

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 <https://bendodson.com/weblog/2014/10/02/showing-todo-as-warning-in-swift-xcode-project/> 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.

<se-0000-pound-warning.md · GitHub

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.

<se-0000-pound-warning.md · GitHub 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")!
}
<se-0000-pound-warning.md · GitHub 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
<se-0000-pound-warning.md · GitHub on existing code

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

<se-0000-pound-warning.md · GitHub 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 <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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

Chris_Lattner · May 29, 2016, 7:44pm

+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

···

On May 28, 2016, at 8:26 PM, Jon Shier via swift-evolution <swift-evolution@swift.org> wrote:

I appreciate the sentiment, but I think we should reserve warnings for actual compiler diagnostics.

Lmpessoa · May 31, 2016, 4:31pm

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 <swift-evolution@swift.org> 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 > <swift-evolution@swift.org> 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-NNNN
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

Erica_Sadun · May 29, 2016, 7:58pm

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

···

On May 29, 2016, at 1:44 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 28, 2016, at 8:26 PM, Jon Shier via swift-evolution <swift-evolution@swift.org> 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

gwendal.roue · May 31, 2016, 4:42pm

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

Gwendal Roué

···

Le 31 mai 2016 à 18:31, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> a écrit :

In your alternatives considered, you mention "not all TODO or FIXME
comments should surface" but I think the opposite

VladimirS · May 31, 2016, 5:37pm

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.

There is some feature of warning that could not be covered by tagged comments: warning could be between `#if` .. `#endif` and so could be raised depends on condition. Comment is just a comment, I think no tool will detect if such comment is in if..#endif or not. You'll see all tagged comments.
I.e. it seems like warning and tagged comments two separate features.

Again, if I *believe* I really need to raise a user-defined warning in some situation, I'll use something like this:

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

and then in code:
TODO(/*My user-defined warning*/)
but I don't think this is the best solution, so I like warning

···

On 31.05.2016 19:31, Leonardo Pessoa via swift-evolution wrote:

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 > <swift-evolution@swift.org> 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 >> <swift-evolution@swift.org> 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-NNNN
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

Chris_Lattner · May 29, 2016, 8:20pm

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

···

On May 29, 2016, at 12:58 PM, Erica Sadun <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.

willstanton · May 29, 2016, 10:09pm

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

harlanhaskins · May 30, 2016, 5:18am

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 <swift-evolution@swift.org> wrote:

On May 29, 2016, at 12:58 PM, Erica Sadun <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 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

Charlie_Monroe1 · May 30, 2016, 5:36am

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

Lmpessoa · May 31, 2016, 5:09pm

That's not what I meant. It's actually the opposite of what I meant. I
don't know if it's the right thing to do to use #warnings as comments
for things do-to or fix.

···

On 31 May 2016 at 13:42, Gwendal Roué <gwendal.roue@gmail.com> wrote:

Le 31 mai 2016 à 18:31, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> 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é

Brent_Royal-Gordon · June 1, 2016, 4:46am

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.

That sounds an awful lot like the way Xcode's templates use warnings:

  func tableView(_ tableView: UITableView, numerOfRowsInSection section: Int) -> Int {
    warning "Implement something useful here."
    return 0
  }

(Incidentally, I prefer `#warning` to `#warning(_:)` here, because I think of the parentheses forms as expressions.)

···

--
Brent Royal-Gordon
Architechies

jrose · June 1, 2016, 5:54pm

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.

···

On May 29, 2016, at 13:20, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On May 29, 2016, at 12:58 PM, Erica Sadun <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.

Lmpessoa · May 29, 2016, 10:49pm

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" <harlan@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

Callionica_Swift · May 30, 2016, 3:22pm

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