[ 
https://issues.apache.org/jira/browse/GROOVY-9442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17054218#comment-17054218
 ] 

mgroovy edited comment on GROOVY-9442 at 3/7/20, 9:54 PM:
----------------------------------------------------------

"The only ve I can see is regex users who might get regex \s mixed up with this 
new escape" implied to me that you would consider supporting \s escapes there 
(since who does not use slashy strings when writing regexs in Groovy ?-) ), but 
good to know G) 


was (Author: emge):
"The only ve I can see is regex users who might get regex \s mixed up with this 
new escape" implied to me that you would consider supporting \s escapes there 
(since who does not use slashy strings when writing regexs in Groovy ?-) ), but 
good to know G-) 

> 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
>            Priority: Major
>         Attachments: screenshot-1.png
>
>
> 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)

Reply via email to