The review of SE-0028 "Modernizing Swift's Debugging Identifiers" ran from January 29… February 2, 2016. The proposal has been *accepted*, with modifications:
* The core team agrees that we should rename all of the existing __FILE__, __LINE__, __COLUMN__, __FUNCTION__, and __DSO_HANDLE__ symbols to lowercase equivalents in the # namespace: #file, #line, #column, #function, #dsohandle. This includes keeping __FUNCTION__, and making #line have the dual behavior of being a directive when it is the first token on a line, but an expression otherwise. Renaming these symbols improves uniformity within the Swift language, and keeping all of them provides a smooth transition path from the old syntax to the new syntax.
* The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule.
* The core team requests that #symbol be split out into a separate proposal, because it needs more detailed design work, and is an additive feature. For example, it might be appealing to provide a "#mangledName” expression that provides the current symbol as a mangled name: when fed into a demangler, a more structured form of the current symbol would be available.
Thank you to Erica Sadun for driving this forward!
The review of SE-0028 "Modernizing Swift's Debugging Identifiers" ran from January 29… February 2, 2016. The proposal has been *accepted*, with modifications:
* The core team agrees that we should rename all of the existing __FILE__, __LINE__, __COLUMN__, __FUNCTION__, and __DSO_HANDLE__ symbols to lowercase equivalents in the # namespace: #file, #line, #column, function, #dsohandle. This includes keeping __FUNCTION__,
The review of SE-0028 "Modernizing Swift's Debugging Identifiers" ran
from January 29… February 2, 2016. The proposal has been *accepted*,
with modifications:
* The core team agrees that we should rename all of the existing
__FILE__, __LINE__, __COLUMN__, __FUNCTION__, and __DSO_HANDLE__
symbols to lowercase equivalents in the # namespace: #file, #line, #column, function, #dsohandle. This includes keeping __FUNCTION__,
and making #line have the dual behavior of being a directive when it
is the first token on a line, but an expression otherwise. Renaming
these symbols improves uniformity within the Swift language, and
keeping all of them provides a smooth transition path from the old
syntax to the new syntax.
* The core team isn’t thrilled with the magic “first token on a line”
whitespace behavior that #line will be getting, and would like someone
to start a discussion about renaming the old #line directive to
something more specific and tailored to its purpose. Once that name
and syntax is settled, we can rename the directive and remove the
whitespace rule.
I'm afraid we'll ultimately need to solve this some other way than by
choosing a different name. We're eventually going to end up with
something meaning #sourceLocation (modulo capitalization) and that's
obviously (IMO) going to be the right name for both entities.
···
on Wed Feb 03 2016, Chris Lattner <swift-evolution@swift.org> wrote:
* The core team requests that #symbol be split out into a separate
proposal, because it needs more detailed design work, and is an
additive feature. For example, it might be appealing to provide a
"#mangledName” expression that provides the current symbol as a
mangled name: when fed into a demangler, a more structured form of the
current symbol would be available.
Thank you to Erica Sadun for driving this forward!
The review of SE-0028 "*Modernizing Swift's Debugging Identifiers*" ran
from January 29… February 2, 2016. The proposal has been **accepted**,
with modifications:
* The core team agrees that we should rename all of the
existing __FILE__, __LINE__, __COLUMN__, __FUNCTION__, and __DSO_HANDLE__
symbols to lowercase equivalents in the # namespace: #file, #line, #column, function, #dsohandle. This includes keeping __FUNCTION__,
To clarify, I meant keeping the behavior of __FUNCTION__, but renaming it
to function.
On the "Renaming #line, the line control statement" thread, Brent Royal-Gordon suggests introducing a different grammar,
specifically:
#reset line=50, file="foo.swift"
that could be applied to all the newly renamed items, not just #line. Is this feasible?
-- Erica
···
On Feb 4, 2016, at 1:24 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
I'm afraid we'll ultimately need to solve this some other way than by
choosing a different name. We're eventually going to end up with
something meaning #sourceLocation (modulo capitalization) and that's
obviously (IMO) going to be the right name for both entities.
* #mangledname, I presume? To retain lowercase?
* Do you want #symbol (e.g. Swift.Dictionary.Foo(_: Int, y: CustomType)) pushed now or saved for post 3.0? (Although SE-0021 is in 2.2?)
* Will #context/#releasecontext/#debugcontext be split out to a separate proposal or dropped entirely?
And thank you all again,
-- E
···
On Feb 3, 2016, at 4:39 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
The review of SE-0028 "Modernizing Swift's Debugging Identifiers" ran from January 29… February 2, 2016. The proposal has been *accepted*, with modifications:
* The core team agrees that we should rename all of the existing __FILE__, __LINE__, __COLUMN__, __FUNCTION__, and __DSO_HANDLE__ symbols to lowercase equivalents in the # namespace: #file, #line, #column, function, #dsohandle. This includes keeping __FUNCTION__,
To clarify, I meant keeping the behavior of __FUNCTION__, but renaming it to function.
* The core team requests that #symbol be split out into a separate proposal, because it needs more detailed design work, and is an additive feature. For example, it might be appealing to provide a "#mangledName” expression that provides the current symbol as a mangled name: when fed into a demangler, a more structured form of the current symbol would be available.
The review of SE-0028 "Modernizing Swift's Debugging Identifiers" ran from January 29… February 2, 2016. The proposal has been *accepted*, with modifications:
* The core team agrees that we should rename all of the existing __FILE__, __LINE__, __COLUMN__, __FUNCTION__, and __DSO_HANDLE__ symbols to lowercase equivalents in the # namespace: #file, #line, #column, function, #dsohandle. This includes keeping __FUNCTION__,
To clarify, I meant keeping the behavior of __FUNCTION__, but renaming it to function.
The review of SE-0028 "Modernizing Swift's Debugging Identifiers" ran from January 29… February 2, 2016. The proposal has been *accepted*, with modifications:
* The core team agrees that we should rename all of the existing __FILE__, __LINE__, __COLUMN__, __FUNCTION__, and __DSO_HANDLE__ symbols to lowercase equivalents in the # namespace: #file, #line, #column, function, #dsohandle. This includes keeping __FUNCTION__,
To clarify, I meant keeping the behavior of __FUNCTION__, but renaming it to function.
* The core team requests that #symbol be split out into a separate proposal, because it needs more detailed design work, and is an additive feature. For example, it might be appealing to provide a "#mangledName” expression that provides the current symbol as a mangled name: when fed into a demangler, a more structured form of the current symbol would be available.
A few q's:
* #mangledname, I presume? To retain lowercase?
Yes, that would make sense. However, the demangler API’s aren’t currently very awesome for Swift, so this may be a theoretical goal. We should discuss whether this idea even makes sense.
* Do you want #symbol (e.g. Swift.Dictionary.Foo(_: Int, y: CustomType)) pushed now or saved for post 3.0? (Although SE-0021 is in 2.2?)
It’s fine to discuss it now. Things that need to be figured out are things like: how specific to make this? In a getter, should it say the getter, or just the property? In a closure within a getter, should it somehow indicate the closure, or just the getter? etc.
* Will #context/#releasecontext/#debugcontext be split out to a separate proposal or dropped entirely?
I think they’d have to be separately motivated by a problem being solved, and being separate is good.
-Chris
···
On Feb 3, 2016, at 5:31 PM, Erica Sadun <erica@ericasadun.com> wrote:
On Feb 3, 2016, at 4:39 PM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
I'm afraid we'll ultimately need to solve this some other way than by
choosing a different name. We're eventually going to end up with
something meaning #sourceLocation (modulo capitalization) and that's
obviously (IMO) going to be the right name for both entities.
I don’t agree with you Dave, these are certainly related, but also very different operations.
On the "Renaming #line, the line control statement" thread, Brent Royal-Gordon suggests introducing a different grammar,
specifically:
#reset line=50, file="foo.swift"
that could be applied to all the newly renamed items, not just #line. Is this feasible?
Yep, something with its own unique grammar would be fine, particularly for the directive form. I’ll comment in the other thread.
-Chris
···
On Feb 4, 2016, at 7:03 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
On Feb 4, 2016, at 1:24 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm afraid we'll ultimately need to solve this some other way than by
choosing a different name. We're eventually going to end up with
something meaning #sourceLocation (modulo capitalization) and that's
obviously (IMO) going to be the right name for both entities.
I don’t agree with you Dave, these are certainly related, but also very different operations.
They both represent source locations. I don't believe they need to have identical names, but they should at least both contain that phrase. I guess if there's a way to distinguish them while keeping the common language for the common concept, that makes renaming enough of a solution. So, I guess I'm agreeing with you.
···
On Feb 4, 2016, at 9:29 AM, Chris Lattner <clattner@apple.com> wrote:
On Feb 4, 2016, at 7:03 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Feb 4, 2016, at 1:24 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On the "Renaming #line, the line control statement" thread, Brent Royal-Gordon suggests introducing a different grammar,
specifically:
#reset line=50, file="foo.swift"
that could be applied to all the newly renamed items, not just #line. Is this feasible?
Yep, something with its own unique grammar would be fine, particularly for the directive form. I’ll comment in the other thread.
No, they don’t, at least not in the same way. The directive only contains the file and line. The expressions can produce the column and function.
These are related, but different.
-Chris
···
On Feb 4, 2016, at 11:17 AM, Dave Abrahams <dabrahams@apple.com> wrote:
On Feb 4, 2016, at 9:29 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Feb 4, 2016, at 7:03 AM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Feb 4, 2016, at 1:24 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I'm afraid we'll ultimately need to solve this some other way than by
choosing a different name. We're eventually going to end up with
something meaning #sourceLocation (modulo capitalization) and that's
obviously (IMO) going to be the right name for both entities.
I don’t agree with you Dave, these are certainly related, but also very different operations.
on Thu Feb 04 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Feb 4, 2016, at 11:17 AM, Dave Abrahams >> <dabrahams@apple.com> wrote:
On Feb 4, 2016, at 9:29 AM, Chris Lattner > >>> <clattner@apple.com >>> <mailto:clattner@apple.com>> wrote:
On Feb 4, 2016, at 7:03 AM, Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org >>>> <mailto:swift-evolution@swift.org>> >>>> wrote:
On Feb 4, 2016, at 1:24 AM, Dave Abrahams via swift-evolution >>>>> <swift-evolution@swift.org >>>>> <mailto:swift-evolution@swift.org>> >>>>> wrote:
I'm afraid we'll ultimately need to solve this some other way than by
choosing a different name. We're eventually going to end up with
something meaning #sourceLocation (modulo capitalization) and that's
obviously (IMO) going to be the right name for both entities.
I don’t agree with you Dave, these are certainly related, but also
very different operations.
They both represent source locations.
No, they don’t, at least not in the same way. The directive only
contains the file and line. The expressions can produce the column
and function.