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

[Chris Lattner]

> 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