[swift-evolution] [Discussion]: Renaming #line, the line control statement

[Erica Sadun]

I'm going to throw this out there so I can get this off my things-to-do list. This proposal puts forth `resetfilecontext` to match Brent's "reset" with Chris's well-specified long symbol: it describes what the command does and is unlikely to overlap with any future identifiers.

Feedback solicited. 

-- E, who is casting her eye on a few other bike sheds and would like this one to be painted purple and done

Disambiguating Line Control Statements from Debugging Identifiers

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
 <https://gist.github.com/erica/8decc791e1319987eadd#introduction>Introduction

In being accepted, Swift Evolution SE-0028 (https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md <https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md>) overloads the use of #line to mean both an identifier that maps to a calling site's line number within a file and acts as part of a line control statement. This proposal nominates #resetfilecontext to replace #line for file and line syntactic source control.

 <https://gist.github.com/erica/8decc791e1319987eadd#motivation>Motivation

Swift uses the the following grammar to define line control statements:

line-control-statement → #line­
line-control-statement → #line­line-number­file-name­
line-number → A decimal integer greater than zero
file-name → static-string-literal­
The accepted implementation of SE-0028 disambiguates the two uses by requiring #line (the control statement) to appear at the first column. This is a stop-gap solution best remedied by renaming #line. 

The core team was not satisfied with the 'first token on a line' whitespace behavior required for overloading #line. Chris Lattner requested a discussion about renaming the old #line directive to something more specific and tailored to its purpose: "Once that name and syntax is settled, we can rename the directive and remove the whitespace rule." Chris also requested a well-specified long symbol, adding:

The existing #line feature exists for a very specific purpose: it is generated by source generation tools (e.g. gyb), and they are designed to change how compiler diagnostics and debug information are emitted. Changing the function/symbol on the debugger isn’t something that is obviously good, because the debugger has a structured notion of the current frame which is a highly symbolic AST representation of the function. A text string is probably not sufficient, and may not be necessary for all cases. The important point though is that any discussion about adding it should be motivated by a concrete use-case, and what problem is being solved.
The discussion took place on-line in the [Discussion]: Renaming #line, the line control statement thread.

 <https://gist.github.com/erica/8decc791e1319987eadd#detailed-design>Detailed design

line-control-statement → #resetfilecontext
line-control-statement → #resetfilecontext line-number file-name
line-number → A decimal integer greater than zero
file-name → static-string-literal­
 <https://gist.github.com/erica/8decc791e1319987eadd#alternatives-considered>Alternatives considered

Several alternatives were put forward, of which #setline was the most popular. This failed the "make it specific and long" (and presumably avoid future naming conflicts) request. 

A more flexible grammar was suggested, however, as Kevin Ballard pointed out, "This feature isn't something end users are going to use. And it's not something that will ever reasonably apply to anything except #file and #line. This feature is only ever intended to be used by tools that auto-generate source files. The most important concerns here really should just be that whatever we use is trivial to generate correctly by even the simplest of tools and is readable. And since this won't ever apply to anything beyond #file and #line, there's no need to try to generalize this feature at all."

A variety of other keywords were put forward in the discussion and can be found in the online discussion.




> On Feb 4, 2016, at 4:06 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Feb 4, 2016, at 1:49 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> I don't think we can support arbitrary replacements for #function, since it's perfectly reasonable for people to write code that expects the format of #function to match what Swift generates.
>> 
>> With a theoretical #sourcecontext (or whatever the proposed name is) that vends different properties for different representations, it's reasonable to have a property that's explicitly intended to be a human-readable description of the function and therefore suitable for letting the description be overridden. But in that case, I'd suggest adding an @attribute to override the human-readable name for the function instead of using a #directive. Two reasons why:
>> 
>> 1. It's reasonable to expect that the description of the function remains constant for the entire function, which means it shouldn't be possible to change the function description halfway through the function, and
>> 2. Unlike file/line, the function context is a stack, and when the function ends, the parent context takes over (e.g. if you have nested functions or closures in a function). And allowing #set-style directives to override the function description seems like it would be confusing; does it replace the current info, or push new info that has to be popped by another directive, or what? Restricting this kind of overriding to an @attribute on the function declaration eliminates this confusion.
> 
> I agree, and I’d add one more point: you didn’t mention a use case.
> 
> The existing #line (and I tend to agree with Kevin’s upthread commentary about #setline) feature exists for a very specific purpose: it is generated by source generation tools (e.g. gyb), and they are designed to change how compiler diagnostics and *debug information* are emitted.  Changing the function/symbol on the debugger isn’t something that is obviously good, because the debugger has a structured notion of the current frame which is a highly symbolic AST representation of the function.  A text string is probably not sufficient, and may not be necessary for all cases.  The important point though is that any discussion about adding it should be motivated by a concrete use-case, and what problem is being solved.
> 
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160208/b55cc594/attachment.html>