[swift-evolution] [swift-evolution-announce] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)

Kevin Ballard kevin at sb.org
Fri Jan 29 14:16:00 CST 2016


> 	* What is your evaluation of the proposal?

+1. Seems like a good idea. But I do want to know why the proposal is leaving __FUNCTION__ alone instead of converting it to #function. All the other screaming snake case identifiers are being renamed, why not __FUNCTION__? I didn't read the original swift-evolution threads, was there some pushback against using the token #function? If so, it would be a good idea to include that in the proposal.

I'd also suggest for the ambiguity with the existing #line directive that maybe the existing directive should be renamed to #setline, since that's really what it's doing.

> 	* Is the problem being addressed significant enough to warrant a change to Swift?

Yeah, the screaming snake case identifiers are an odd wart on the language.

> 	* Does this proposal fit well with the feel and direction of Swift?

Yes.

> 	* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

C has precedent for __FOO__ identifiers, which is why those make sense there. But other languages that don't have the __FOO__ precedent don't typically use __FILE__, __LINE__, e.g. for their equivalent functionality. For example, Rust uses the compiler-implemented macros file!(), line!(), etc. for this functionality. It makes sense for Swift to use e.g. #file for the same reasons that Rust uses file!().

> 	* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick reading of the proposal.

-Kevin Ballard


More information about the swift-evolution mailing list