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

[Erica Sadun]

> On Jan 29, 2016, at 1:16 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 	* 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.

Function could be dropped, because it's picked up through #symbol. This is also why the proposal doesn't introduce #module, #type, etc the way earlier drafts discussed.

> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution