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

Curt Clifton curt at omnigroup.com
Sat Jan 30 18:39:25 CST 2016


> The proposal is available here:
> 
>    https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md

>    * What is your evaluation of the proposal?

I am in favor of the proposal. 

As far as the detailed design decisions, I'm in favor of adding including #symbol and #function.

I continue to prefer #sourcelocation and a SourceLocation type as the right design ultimately, but think the current proposal is a sensible first step towards normalization (and may prove sufficient in practice).

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

Yes. 

Normalizing the syntax of compiler magic reduces the complexity of the language and allows users to learn to associate octothorp with a set of expressions/operations. That ultimately makes discovery easier as well. E.g., I know what section of the docs to look at to find the thing I recall exists but don't know how to spell.

>    * 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?

The current snake case was natural from a C/Obj-C background. Obj-C adds `_cmd` to the mix. The proposed octothorp-prefixed expressions provides similar expressiveness with a Swiftier syntax.

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

I skim the original subthread in the review of SE-0022. I read and participated in the full thread workshopping the draft of the current proposal. I read the current proposal a couple of times to be sure I didn't miss anything.

Cheers, 

Curt
------------------------- 
Curt Clifton, PhD 
Software Developer 
The Omni Group 
www.curtclifton.net 



More information about the swift-evolution mailing list