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

[Kevin Ballard]

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.

-Kevin Ballard

On Thu, Feb 4, 2016, at 01:40 PM, Brent Royal-Gordon wrote:
> > And it's not something that will ever reasonably apply to anything except #file and #line.
> 
> Why not `#function`, at least? `#function` is a human-readable indication of the surrounding unit of code. It's not intended to be used to look things up in the compiled file. If you're generating code from a definition somewhere, shouldn't `#function` properly reference that definition, not whatever random garbage your generator spat out because it was easier to structure the generated code that way?
> 
> Certainly `#dsoHandle` and the hypothetical `#mangledName`, which refer to locations in compiled code and can be used to look code up at runtime, shouldn't be settable, but I think all of the things that point to source code locations ought to be fair game.
> 
> -- 
> Brent Royal-Gordon
> Architechies
>