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

Brent Royal-Gordon brent at architechies.com
Fri Feb 5 16:22:12 CST 2016

> 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)")

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

More information about the swift-evolution mailing list