[jira] [Closed] (GROOVY-9442) GEP: Support for the new JDK14 string escape sequence (\s for single space)

["Paul King (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GROOVY-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul King closed GROOVY-9442.
-----------------------------

> GEP: Support for the new JDK14 string escape sequence (\s for single space)
> ---------------------------------------------------------------------------
>
>                 Key: GROOVY-9442
>                 URL: https://issues.apache.org/jira/browse/GROOVY-9442
>             Project: Groovy
>          Issue Type: New Feature
>          Components: GEP
>            Reporter: Paul King
>            Assignee: Paul King
>            Priority: Major
>             Fix For: 3.0.3
>
>         Attachments: screenshot-1.png
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> The goal is to add {{\s}} as an additional escape sequence for single and double quoted strings.
> {code:java}
> assert 'ab\scd\s'.bytes == [97, 98, 32, 99, 100, 32]
> {code}
> Relevant section from the Java issue tracker ([JEP 368: Text Blocks (Second Preview)|https://bugs.openjdk.java.net/browse/JDK-8231623]):
> {quote}!screenshot-1.png|width=804,height=265!
> {quote}
> This isn't a breaking change since:
>  * illegal escape sequences are currently an error for single and triple (multi-line) single/double quoted strings
>  * slashy and dollar slashy strings ignore backslash escape sequences (apart from special cases)
> The use case cited in Java is to allow explicit indication of spaces at the end of a line in a multi-line string. This is then explicit for human readers or editors that might auto-remove trailing spaces. It becomes more important in recent versions of Java with auto-removal of incidental whitespace in multi-line strings.
> Note: I don't want to pre-empt implementation details, but I imagine in Groovy's case (since we don't auto-remove incidental whitespace) we will do translation during parsing and won't have the same rule as per Java above about translating after incidental whitespace removal.
> So, we could do this now (shown for Groovy 3):
> {code}
> String colors = '''\
>     red   \n\
>     green \n\
>     blue  \n\
> '''.stripIndent(true)
> assert colors.readLines()*.size() == [6, 6, 6]
> {code}
> After this change, you could also do:
> {code}
> String colors = '''\
>     red  \s
>     green\s
>     blue \s
> '''.stripIndent(true)
> assert colors.readLines()*.size() == [6, 6, 6]
> {code}
> The only -ve I can see is regex users who might get regex \s mixed up with this new escape. But we already have that issue for \b (backspace in normal string vs word boundary in regex), so this is almost a non-issue.
> See also: [Existing Groovy escape sequences|https://groovy-lang.org/syntax.html#_escaping_special_characters]



--
This message was sent by Atlassian Jira
(v8.3.4#803005)