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

[Kevin Ballard]

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> 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> 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> wrote:
>>>> Swift Evolution SE-0028
>>>> (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[1]­**file-
>>>> name[2]­* *line-number *→ A decimal integer greater than zero *file-
>>>> name *→ *static-string-literal[3]­*
>>>>
>>>> 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
>>>> 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
> _________________________________________________
> swift-evolution mailing list swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



Links:

  1. https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number
  2. https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
  3. https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160203/ba3d68db/attachment.html>