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.
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@swift.org> wrote:
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.
line-control-statement → #line
line-control-statement → #lineline-numberfile-name
line-number → A decimal integer greater than zero
file-name → 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.
I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?
#reset line=50, file="foo.swift"
(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)
Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set function to the name of the rule a particular piece of code came from.
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@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@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 → #lineline-numberfile-name
line-number → A decimal integer greater than zero
file-name → 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.
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.
I'm in favor of #setline. It has as nice match to #line because #setline
changes the value that #line returns.
-Kevin Ballard
#source is already earmarked for future directions.
I'm thinking #setline and #sourceline are both good.
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
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.
*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.
On Wed, Feb 3, 2016, at 06:19 PM, Erica Sadun via swift-evolution wrote:
On Feb 3, 2016, at 6:58 PM, Sean Heber <sean@fifthace.com> wrote:
On Feb 3, 2016, at 7:32 PM, Jonathan Tang via swift-evolution <swift- >> evolution@swift.org> wrote:
On Wed, Feb 3, 2016 at 5:24 PM, Erica Sadun via swift-evolution <swift- >>> evolution@swift.org> wrote:
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@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@fifthace.com <mailto:sean@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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:
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.
#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@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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:
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.
Is it true that this feature is only for the purpose of debug symbols /
compiler message locations? If so, what about including the word "debug",
such as #debugline ?
···
On Wed, Feb 3, 2016 at 7:29 PM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:
> line-control-statement → #line
> line-control-statement → #lineline-numberfile-name
> line-number → A decimal integer greater than zero
> file-name → 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.
I don't love the way the current format has two unlabeled parameters in an
arbitrary order. Maybe something more like this?
#reset line=50, file="foo.swift"
(I have a soft preference for "reset" over "set" because these are things
the compiler changes automatically, but that might be a silly reason.)
Perhaps this could even let you set any combination of the #whatever
parameters, so if, for instance, you were writing a parser generator, you
could set function to the name of the rule a particular piece of code came
from.
I like the idea of generalizing this a lot more than just going with #setline, which is otherwise currently the most popular response in this thread.
-- E
···
On Feb 3, 2016, at 8:29 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
line-control-statement → #line
line-control-statement → #lineline-numberfile-name
line-number → A decimal integer greater than zero
file-name → 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.
I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?
#reset line=50, file="foo.swift"
(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)
Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set function to the name of the rule a particular piece of code came from.
+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@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@swift.org <mailto:swift-evolution@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@fifthace.com <mailto:sean@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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:
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.
Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:
#setsyntacticsourcelocation
or something. :-)
-Chris
···
On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
line-control-statement → #line
line-control-statement → #lineline-numberfile-name
line-number → A decimal integer greater than zero
file-name → 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.
I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?
#reset line=50, file="foo.swift"
(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)
Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set function to the name of the rule a particular piece of code came from.
Is compatibility with the C preprocessor and other preprocessors that emit #line directives a non-goal for Swift?
I guess we probably don’t want to encourage (ab-)use of the C preprocessor and one could easily translate #line directives to Swift’s syntax by preprocessing the preprocessor output with sed, but I’m curious.
-- adrian
···
On Feb 4, 2016, at 9:31 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
line-control-statement → #line
line-control-statement → #lineline-numberfile-name
line-number → A decimal integer greater than zero
file-name → 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.
I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?
#reset line=50, file="foo.swift"
(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)
Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set function to the name of the rule a particular piece of code came from.
Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:
On Feb 4, 2016, at 10:31 AM, Chris Lattner <clattner@apple.com> wrote:
On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
line-control-statement → #line
line-control-statement → #line line-number file-name
line-number → A decimal integer greater than zero
file-name → 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.
I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?
#reset line=50, file="foo.swift"
(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)
Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set function to the name of the rule a particular piece of code came from.
Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:
line-number → A decimal integer greater than zero
file-name → 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.
I don't love the way the current format has two unlabeled parameters
in an arbitrary order. Maybe something more like this?
#reset line=50, file="foo.swift"
(I have a soft preference for "reset" over "set" because these are
things the compiler changes automatically, but that might be a silly
reason.)
Perhaps this could even let you set any combination of the #whatever
parameters, so if, for instance, you were writing a parser
generator, you could set function to the name of the rule a
particular piece of code came from.
Using something like this as the grammar structure makes sense to me,
but I’d suggest something more specific (and longer) for this,
perhaps:
Something like this makes sense to me, but only file and line can really be set by this construct.
-Chris
···
On Feb 4, 2016, at 9:46 AM, Erica Sadun <erica@ericasadun.com> wrote:
-- E
On Feb 4, 2016, at 10:31 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
line-control-statement → #line
line-control-statement → #line line-number file-name
line-number → A decimal integer greater than zero
file-name → 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.
I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?
#reset line=50, file="foo.swift"
(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)
Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set function to the name of the rule a particular piece of code came from.
Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:
* It offers a specific identifier that's unlikely to conflict with future keywords
* It enables the grammar to expand for future syntactic control assignments
* It adds labels so dropped arguments and arbitrary order are easily disambiguated (thanks BRG)
I know Brent prefers reset to set (#resetsyntaxcontext to #setsyntaxcontext), and wanted to punch that point again here.
-- E
···
On Feb 4, 2016, at 10:49 AM, Chris Lattner <clattner@apple.com> wrote:
On Feb 4, 2016, at 9:46 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
Something like this makes sense to me, but only file and line can really be set by this construct.
-Chris
-- E
On Feb 4, 2016, at 10:31 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:
On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
line-control-statement → #line
line-control-statement → #line line-number file-name
line-number → A decimal integer greater than zero
file-name → 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.
I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?
#reset line=50, file="foo.swift"
(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)
Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set function to the name of the rule a particular piece of code came from.
Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:
It is a non-goal. “clang -E” generates a ton of weird forms that we don’t want or need to support.
-Chris
···
On Feb 4, 2016, at 10:38 AM, Adrian Prantl <aprantl@apple.com> wrote:
#setsyntacticsourcelocation
or something. :-)
Is compatibility with the C preprocessor and other preprocessors that emit #line directives a non-goal for Swift?
I guess we probably don’t want to encourage (ab-)use of the C preprocessor and one could easily translate #line directives to Swift’s syntax by preprocessing the preprocessor output with sed, but I’m curious.
This feature isn't something end users are going to use. And it's not
something that will ever reasonably apply to anything except #file and #line. This feature is only ever intended to be used by tools that auto-
generate source files. The most important concerns here really should
just be that whatever we use is trivial to generate correctly by even
the simplest of tools and is readable. And since this won't ever apply
to anything beyond #file and #line, there's no need to try to generalize
this feature at all.
To that end, since the precedent here is for the compiler directive #line, I repeat my +1 for #setline. It has the verb, which Greg Parker
rightly points out is a good idea, and it's the simplest solution that
happens to be the closest to the existing precedent (which will help
because any tools that generate these directives for multiple languages,
or for multiple versions of Swift, only have to include/omit the word
"set" instead of generating two completely different directives, and
similarly it becomes trivial to take tools that generate #line
directives and fix up the output with something like `tool | sed
's/^#line\b/#setline/').
-Kevin Ballard
···
On Thu, Feb 4, 2016, at 09:55 AM, Erica Sadun via swift-evolution wrote:
* It offers a specific identifier that's unlikely to conflict with
future keywords
* It enables the grammar to expand for future syntactic control
assignments
* It adds labels so dropped arguments and arbitrary order are easily
disambiguated (thanks BRG)
I know Brent prefers reset to set (#resetsyntaxcontext to #setsyntaxcontext), and wanted to punch that point again here.
-- E
On Feb 4, 2016, at 10:49 AM, Chris Lattner >> <clattner@apple.com> wrote:
On Feb 4, 2016, at 9:46 AM, Erica Sadun <erica@ericasadun.com> >>> wrote:
Something like this makes sense to me, but only file and line can
really be set by this construct.
-Chris
-- E
On Feb 4, 2016, at 10:31 AM, Chris Lattner <clattner@apple.com> >>>> wrote:
On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution >>>>> <swift-evolution@swift.org> wrote:
line-control-statement → #line line-control-statement → #line
line-number file-name line-number → A decimal integer greater
than zero file-name → 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.
I don't love the way the current format has two unlabeled
parameters in an arbitrary order. Maybe something more like this?
#reset line=50, file="foo.swift"
(I have a soft preference for "reset" over "set" because these are
things the compiler changes automatically, but that might be a
silly reason.)
Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a
parser generator, you could set function to the name of the rule
a particular piece of code came from.
Using something like this as the grammar structure makes sense to
me, but I’d suggest something more specific (and longer) for this,
perhaps:
And it's not something that will ever reasonably apply to anything except #file and #line.
Why not `#function`, at least? `#function` is a human-readable indication of the surrounding unit of code. It's not intended to be used to look things up in the compiled file. If you're generating code from a definition somewhere, shouldn't `#function` properly reference that definition, not whatever random garbage your generator spat out because it was easier to structure the generated code that way?
Certainly `#dsoHandle` and the hypothetical `#mangledName`, which refer to locations in compiled code and can be used to look code up at runtime, shouldn't be settable, but I think all of the things that point to source code locations ought to be fair game.