[swift-evolution] [Discussion]: Renaming #line, the line control statement

[Jean-Daniel Dupas]

+1 for using a verb. We don’t need that statement to be short, we just need it to avoid any potential future conflict and so we can make it explicit.

#setline or #setlocation as it does not just change the line, but may change the filename too.

> Le 4 févr. 2016 à 04:13, Greg Parker via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> I like something that has a verb. We don't expect humans to write this directive, so we should optimize to prevent accidental use of this where you really wanted #line. #setline is better than #sourceline by that metric.
> 
>> On Feb 3, 2016, at 6:54 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> I'm in favor of #setline. It has as nice match to #line because #setline changes the value that #line returns.
>>  
>> -Kevin Ballard
>>  
>> On Wed, Feb 3, 2016, at 06:19 PM, Erica Sadun via swift-evolution wrote:
>>> #source is already earmarked for future directions.
>>>  
>>> I'm thinking #setline and #sourceline are both good.
>>>  
>>>> On Feb 3, 2016, at 6:58 PM, Sean Heber <sean at fifthace.com <mailto:sean at fifthace.com>> wrote:
>>>>  
>>>> I like that reasoning. I'd suggest even simpler and go with #source since it also can include a file name.
>>>>  
>>>> l8r
>>>> Sean
>>>>  
>>>> Sent from my iPad
>>>>  
>>>> On Feb 3, 2016, at 7:32 PM, Jonathan Tang via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> The primary use for the existing #line directive is for generated code like parser/lexer generators, right?  If so, how about #sourceline, since it represents the line number in the original source code?  I'm also fine with #setline, but don't like #linenumber because it's not clear what the difference is between it and #line.
>>>>>  
>>>>> Actually, it'd also be used to reset the line number back to the generated code, right?  In that case, #sourceline seems awkward, and maybe I'll just go with +1 to #setline.
>>>>>  
>>>>> On Wed, Feb 3, 2016 at 5:24 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> Swift Evolution SE-0028 (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>) overloads
>>>>> the use of #line to mean both an identifier that maps to a calling site's line number with a file and acts as part of a line control statement with the following grammar:
>>>>>  
>>>>> line-control-statement → #line­
>>>>>  <>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name>­
>>>>>  <>line-number → A decimal integer greater than zero
>>>>>  <>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal>­
>>>>>  
>>>>> The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line. 
>>>>>  
>>>>> Chris Lattner writes, "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'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.
>>>>>  
>>>>> Best, -- E
>>>>>  
>>>>>  
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>  
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>  
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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