or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* 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?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
+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?
* What is your evaluation of the proposal?
+1, I like the idea and the implemntation.
* Is the problem being addressed significant enough to warrant a change to
Swift?
Yes, it helps make the language more cohesive.
* Does this proposal fit well with the feel and direction of Swift?
Absolutely. It brings the syntax in line with the language at large.
* If you have you used other languages or libraries with a similar feature,
how do you feel that this proposal compares to those?
I feel it is less jarring to read.
* How much effort did you put into your review? A glance, a quick reading,
or an in-depth study?
A quick reading fo the fianl proposal but I followed the discussion closely.
···
On Fri, Jan 29, 2016 at 11:31 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
Hello Swift community,
The review of "Modernizing Swift's Debugging Identifiers" begins now and
runs through February 2nd. The proposal is available here:
or, if you would like to keep your feedback private, directly to the
review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a
change to Swift?
* 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?
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
More information about the Swift evolution process is available at
- What is your evaluation of the proposal?
- +1. This change makes the language more consistent in symbology and
naming.
- Is the problem being addressed significant enough to warrant a change
to Swift?
- Yes, consistency is important.
- 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?
- Besides C/C++ from which the current names are based, I've used Rust,
which has vary similar naming to this proposal (line!, column!,
file!). The
exclamation point suffix there is for a macro expanded by the compiler,
similar to the # prefix in Swift.
- How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
- I've read and been involved in the swift-evolution thread from the
beginning.
···
On Fri, Jan 29, 2016 at 2:31 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
Hello Swift community,
The review of "Modernizing Swift's Debugging Identifiers" begins now and
runs through February 2nd. The proposal is available here:
or, if you would like to keep your feedback private, directly to the
review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a
change to Swift?
* 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?
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
More information about the Swift evolution process is available at
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* 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?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
I am mostly concerned by the ambiguity of the new #line _identifier_ with the existing #line _directive_. As the proposal mentions, the two can be syntactically disambiguated by constraining the #line directive to column 1. Aesthetically, using the same #ident syntax for identifiers that grammatically behave like literals and for compiler directives that trigger an action during compilation seems a little inconsistent to me.
Like the __LINE__ identifier the #line directive inherited its syntax from the C preprocessor. In the case of the #line directive, there is value in using this inherited syntax because it is compatible with many preprocessing tools and code generators that output this format. If we change the syntax of the #line directive, we’re no longer compatible with these tools.
* What is your evaluation of the proposal?
I support the variant of the proposal that renames the __LINE__ identifier to #linenumber.
* Is the problem being addressed significant enough to warrant a change to Swift?
N/A
* Does this proposal fit well with the feel and direction of Swift?
Yes
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I'm +1 on this. In my opinion it aligns well with other static compiler directives such as `#selector`, `#available`, #if`.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, those identifiers are used often when debugging (especially logging).
Does this proposal fit well with the feel and direction of Swift?
Definetely yes. It removes yet another C artifact which cannot be justified in any way except of familiarity. Also, `#`-prefixed keywords fit well with other compiler expressions (this argument was mentioned in the proposal itself).
If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Obviously, in C family languages. As C family libraries and frameworks tend to name their basic constants using `__SCREAMING_SNAKE_CASE__` format so that `__FILE__` fits well among them, it is not the case in Swift.
Pozdrawiam – Regards,
Adrian Kashivskyy
···
Wiadomość napisana przez Chris Lattner via swift-evolution <swift-evolution@swift.org> w dniu 29.01.2016, o godz. 20:31:
Hello Swift community,
The review of "Modernizing Swift's Debugging Identifiers" begins now and runs through February 2nd. The proposal is available here:
or, if you would like to keep your feedback private, directly to the review manager.
What goes into a review?
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change to Swift?
* 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?
* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
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
On Jan 29, 2016, at 11:49, Adrian Kashivskyy via swift-evolution <swift-evolution@swift.org> wrote:
What is your evaluation of the proposal?
I'm +1 on this. In my opinion it aligns well with other static compiler directives such as `#selector`, `#available`, #if`.
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, those identifiers are used often when debugging (especially logging).
Does this proposal fit well with the feel and direction of Swift?
Definetely yes. It removes yet another C artifact which cannot be justified in any way except of familiarity. Also, `#`-prefixed keywords fit well with other compiler expressions (this argument was mentioned in the proposal itself).
If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Obviously, in C family languages. As C family libraries and frameworks tend to name their basic constants using `__SCREAMING_SNAKE_CASE__` format so that `__FILE__` fits well among them, it is not the case in Swift.
+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.
···
On Jan 29, 2016, at 1:16 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
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?
So you're expecting another proposal to introduce #symbol and to be accepted for the same Swift release?
I'd think it makes more sense to have this proposal replace __FUNCTION__ with function for now, and then a separate proposal that introduces #symbol would override that to remove function entirely. If both proposals make it into the same Swift release then we'd never actually have function at all, but by doing it this way, if the #symbol proposal doesn't make it into the same release, or is rejected, then we'd end up with function instead of leaving __FUNCTION__ around as the lone screaming snake case identifier.
-Kevin Ballard
···
On Fri, Jan 29, 2016, at 12:25 PM, Erica Sadun wrote:
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.
The choice of #symbol and/or function are both included in the detailed design for this proposal.
I do not intend to propose again to introduce #symbol.
-- Erica
···
On Jan 29, 2016, at 2:06 PM, Kevin Ballard <kevin@sb.org> wrote:
On Fri, Jan 29, 2016, at 12:25 PM, Erica Sadun wrote:
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.
So you're expecting another proposal to introduce #symbol and to be accepted for the same Swift release?
I'd think it makes more sense to have this proposal replace __FUNCTION__ with function for now, and then a separate proposal that introduces #symbol would override that to remove function entirely. If both proposals make it into the same Swift release then we'd never actually have function at all, but by doing it this way, if the #symbol proposal doesn't make it into the same release, or is rejected, then we'd end up with function instead of leaving __FUNCTION__ around as the lone screaming snake case identifier.
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.
So you're expecting another proposal to introduce #symbol and to be accepted for the same Swift release?
I'd think it makes more sense to have this proposal replace __FUNCTION__ with function for now, and then a separate proposal that introduces #symbol would override that to remove function entirely. If both proposals make it into the same Swift release then we'd never actually have function at all, but by doing it this way, if the #symbol proposal doesn't make it into the same release, or is rejected, then we'd end up with function instead of leaving __FUNCTION__ around as the lone screaming snake case identifier.
+1. At least one of the two should be accepted as part of this proposal.
···
On Jan 29, 2016, at 3:06 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
On Fri, Jan 29, 2016, at 12:25 PM, Erica Sadun wrote:
+1 from me as I prefer to say octothorpe to sharp or pound and I don't like snakes! :-) Seriously though the proposed solution is easier on the eyes when you encounter them.