[swift-evolution] [Review] SE-0028 Modernizing Swift's Debugging Identifiers (__LINE__, etc)
curt at omnigroup.com
Sat Jan 30 18:39:25 CST 2016
> The proposal is available here:
> * 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?
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?
> * 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.
Curt Clifton, PhD
The Omni Group
More information about the swift-evolution