[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