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

Dave Abrahams dabrahams at apple.com
Thu Feb 4 13:17:59 CST 2016


> On Feb 4, 2016, at 9:29 AM, Chris Lattner <clattner at apple.com> wrote:
> 
> 
>> On Feb 4, 2016, at 7:03 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>>> On Feb 4, 2016, at 1:24 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 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
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160204/3df4eabd/attachment.html>


More information about the swift-evolution mailing list