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

[Brent Royal-Gordon]

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

But `#function` is not a structured representation of the function name suitable for debugger use, is it? It's not machine-parseable.

Here's my use case. I know a programmer who, in Objective-C, frequently uses a macro equivalent to this:

	func trace(functionName: StaticString = #function) {
		#if TRACE
			print("In \(functionName)")
		#endif
	}

He sprinkles these throughout his code and turns them on when he's trying to debug something where he thinks it'd be helpful.

Now, imagine this guy wants to use his `trace()` function with a hypothetical Swift version of yacc, which like all yaccs writes an enormous ball of unreadable code in one big function for efficiency. So he writes a bunch of rules like:

	expression	:	expression '+' expression {
						trace()
						return FunctionCallNode("+", [$1, $3])
					}

What does `trace()` print? Normally it would print something like "Parser.yyparse()", but wouldn't it be better to have it print "action for rule `expression: expression '+' expression`"?

I think these debug identifiers are best modeled as being split into two sets. #file, #line, #column, and #function (whatever it ends up being called) identify a location in source code and are, at least in theory, modifiable. #dsohandle and a hypothetical #mangledfunction (whatever it ends up being called) identify a location in compiled code and are not modifiable. (There might even be a third one of these representing the current offset into the function, as we see in crash reports.)

Even if we don't decide to do this now, I think we're better off choosing a syntax that can support this feature later. A syntax with name-value pairs is clearer anyway, and it also leaves the door open for us to do something like what I'm describing in the future.

-- 
Brent Royal-Gordon
Architechies