[Review[ SE-0034 Disambiguating Line Control Statements from Debugging Identifiers

Hello Swift community,

The review of "Disambiguating Line Control Statements from Debugging Identifiers" begins now and runs through February 22. The proposal is available here:

  swift-evolution/0034-disambiguating-line.md at master · apple/swift-evolution · GitHub

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Swift Intern

Detailed design

line-control-statement → #setline
line-control-statement → #setline line-number file-name
line-number → A decimal integer greater than zero
file-name → static-string-literal­

Nitpick: #setline is not really a statement, a better name for the production would be “line-control-directive” as it may appear everywhere a newline character may appear in the grammar.

I’d like to propose “#resetline” as a more self-explanatory alternative to the empty #setline directive. (The empty #line directive restores the the parser to continue with normal source locations — a feature used by LLDB).

  * What is your evaluation of the proposal?

+1 with the above suggestions.

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, we don’t want two different concepts named #line.

  * Does this proposal fit well with the feel and direction of Swift?

Yes, since it is a stated non-goal to maintain compatibility with the C preprocessor.

-- adrian

···

On Feb 17, 2016, at 8:39 PM, Chris Lattner <clattner@apple.com> wrote:

Hello Swift community,

The review of "Disambiguating Line Control Statements from Debugging Identifiers" begins now and runs through February 22. The proposal is available here:

  https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md

Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
  https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager.

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

  * What is your evaluation of the proposal?

Seems like SE-0028 created an undesirable side-effect that needs remediation, and hence I approve. Does the community needs to do a better job fleshing out these details moving forward, or was this intentional?

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

  * Does this proposal fit well with the feel and direction of Swift?

Yes.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Don't know.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Quick read.

···

On Feb 17, 2016, at 11:39 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

  https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Swift Intern
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

  https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md

Not a full review yet, just a question:

line-control-statement → #setline
line-control-statement → #setline line-number file-name

Does that mean the filename is always required? This is uncommon in other languages that support #line, though it looks like Swift 2 imposes the same requirement.

···

--
Brent Royal-Gordon
Architechies

I'm going to defer to the team to answer this.

···

On Feb 18, 2016, at 7:16 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

  https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md

Not a full review yet, just a question:

line-control-statement → #setline
line-control-statement → #setline line-number file-name

Does that mean the filename is always required? This is uncommon in other languages that support #line, though it looks like Swift 2 imposes the same requirement.

--
Brent Royal-Gordon
Architechies

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

Adrian Prantl wrote:

Nitpick: #setline is not really a statement, a better name for the production would be “line-control-directive” as it may appear everywhere a newline character may appear in the grammar.

Agreed.

The reference doesn't currently separate directives (if and #setline and so on) into their own chapter. Given the list of chapters it does have, Statements was the least incorrect place to discuss these.

We'll have to revisit the naming on these "statements" that aren't quite statements in the grammar. This is very closely related to the recent change to rename "build configurations" to "conditional compilation blocks". (As commit 6272941 did for compiler diagnostics.)

Brent Royal-Gordon wrote:

Does that mean the filename is always required? This is uncommon in other languages that support #line, though it looks like Swift 2 imposes the same requirement.

You're correct, that is the current behavior (see below). Do you have an example use case for setting the line number without setting the file name?

% cat -n test.swift
     1 print("On line \(#line) in file \(#file)")
     2
     3 print("On line \(#line) in file \(#file)")
     4
     5 #line 100
     6
     7 print("On line \(#line) in file \(#file)")
     8
     9 #line 100 "filename"
    10
    11 print("On line \(#line) in file \(#file)")
    12
    13 #line
    14
    15 print("On line \(#line) in file \(#file)")

% swift test.swift
test.swift:7:1: error: expected filename string literal for #line directive
print("On line \(#line) in file \(#file)")
^