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

Chris Lattner clattner at apple.com
Wed Feb 3 22:37:55 CST 2016

> On Feb 3, 2016, at 5:31 PM, Erica Sadun <erica at ericasadun.com> wrote:
>>> On Feb 3, 2016, at 4:39 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>> Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md <https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md>
>>> 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160203/880183ed/attachment.html>

More information about the swift-evolution mailing list