allow escaping newlines with \ inside strings
#40753
Conversation
simeonschaub
added
parser
simeonschaub
force-pushed
the
sds/string_line_continuation
branch
2 times, most recently
from
6f454e8
to
d7263a1
Compare
simeonschaub
force-pushed
the
sds/string_line_continuation
branch
from
d7263a1
to
8600586
Compare
|
Bump. Is this good to go? |
This allows the use of `\` in front of newlines inside non-raw/non-custom string or command literals as a line continuation character, so the following newline is ignored. This way, long strings without any newlines in them don't have to be written in a single line or be broken up. I think we might also want to use this to improve the printing of long strings in the REPL by printing them as multiline strings, making use of `\` for long lines if necessary, but that can be discussed separately. The command literal part is technically breaking, but the current behavior is probably unintuitive enough that this can be considered a minor change. For string literals, this should be entirely non-breaking since a single `\` before a newline currently throws a parsing error. closes #37728
simeonschaub
force-pushed
the
sds/string_line_continuation
branch
from
5579e2d
to
9d6c791
Compare
Co-authored-by: Jameson Nash <[email protected]>
|
Failures are definitely unrelated, but I would feel more comfortable if we could verify that this passes on Windows as well, to make sure we don't introduce any platform-related newline issues. |
NEWS.md
Outdated
| @@ -16,6 +16,9 @@ New language features | |||
| in `[A; B]` has always described concatenating along the first dimension (vertically), now two | |||
| semicolons `[A;; B]` do so in the second dimension (horizontally), three semicolons `;;;` in the | |||
| third, and so on. ([#33697]) | |||
| * A backslash (`\`) before a newline inside a string literal now escapes the newline while also | |||
There was a problem hiding this comment.
I think it's unclear what "escapes" means here; sometimes escaping a character means including it, e.g. "\"".
There are also manual sections on string literals that should mention this.
|
Let me voice a concern about this: if we do this we cannot ever allow backslash escaping spaces or tabs because if we do that then with this feature you would be visually unable to tell what a program does — you would have to check to make sure that what's after an apparently trailing backslash is actually a newline and not some invisible trailing whitespace characters before the newline. Yes, whether those trailing spaces are there or not in a quote affects the program behavior either way in the sense that anything inside of quotes like that affects program behavior, but I think that this would mean that invisible trailing whitespace might affect program behavior in a much more significant way than merely being there. Currently we error if you try to escape a space or a tab in a string literal, so we're ok as this stands, but I just wanted to point it out. |
|
Markdown assigns meaning to trailing |
This allows the use of `\` in front of newlines inside non-raw/non-custom string or command literals as a line continuation character, so the following newline is ignored. This way, long strings without any newlines in them don't have to be written in a single line or be broken up. I think we might also want to use this to improve the printing of long strings in the REPL by printing them as multiline strings, making use of `\` for long lines if necessary, but that can be discussed separately. The command literal part is technically breaking, but the current behavior is probably unintuitive enough that this can be considered a minor change. For string literals, this should be entirely non-breaking since a single `\` before a newline currently throws a parsing error. closes JuliaLang#37728
This allows the use of `\` in front of newlines inside non-raw/non-custom string or command literals as a line continuation character, so the following newline is ignored. This way, long strings without any newlines in them don't have to be written in a single line or be broken up. I think we might also want to use this to improve the printing of long strings in the REPL by printing them as multiline strings, making use of `\` for long lines if necessary, but that can be discussed separately. The command literal part is technically breaking, but the current behavior is probably unintuitive enough that this can be considered a minor change. For string literals, this should be entirely non-breaking since a single `\` before a newline currently throws a parsing error. closes JuliaLang#37728
This allows the use of
\in front of newlines insidenon-raw/non-custom string or command literals as a line continuation
character, so the following newline is ignored. This way, long strings
without any newlines in them don't have to be written in a single line
or be broken up. I think we might also want to use this to improve the
printing of long strings in the REPL by printing them as multiline
strings, making use of
\for long lines if necessary, but that can bediscussed separately.
The command literal part is technically breaking, but the current
behavior is probably unintuitive enough that this can be considered a
minor change. For string literals, this should be entirely non-breaking
since a single
\before a newline currently throws a parsing error.closes #37728