Message342569
For the record, I just came across this proposed feature for Java:
https://openjdk.java.net/jeps/8222530
Add text blocks to the Java language. A text block is a multi-line
string literal that avoids the need for most escape sequences,
automatically formats the string in predictable ways, and gives the
developer control over format when desired.
It seems to be similar to Python triple-quoted strings except that the
compiler automatically dedents the string using a "re-indentation
algorithm". (Which sounds to me similar to, if not identical, to that
used by textwrap.)
The JEP proposal says:
A study of Google's large internal repository of Java source code
showed that 98% of string literals, once converted to text blocks
and formatted appropriately, would require removal of incidental
white space. If Java introduced multi-line string solution without
support for automatically removing incidental white space, then many
developers would write a method to remove it themselves and/or lobby
for the String class to include a removal method.
which matches my own experience: *most* but not all of my indented
triple-quotes strings start with incidental whitespace that I don't care
about. But not quite all, so I think backwards compatibility requires
that *by default* triple-quoted strings are not dedented.
Note that there are a couple of major difference between the JEP
proposal and this:
- The JEP proposes to automatically dedent triple-quoted strings;
this proposal requires an explicit call to .dedent().
- The JEP proposal allows the user to control the dedent by
indenting, or not, the trailing end-quote;
- however that means that in Java you won't be able to control
the dedent if the string doesn't end with a final blank line;
- Should the dedent method accept an optional int argument
specifying the number of spaces to dedent by? (Defaulting to
None, meaning "dedent by the common indent".) If so, that won't
affect the compile-time optimization so long as the argument is
a literal.
- the JEP performs the dedent before backslash escapes are
interpreted; in this proposal backslash escapes will
occur before the dedent.
The JEP also mentions considering multi-line string literals as Swift
and Rust do them:
https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md
https://stackoverflow.com/questions/29483365/what-is-the-syntax-for-a-multiline-string-literal
I mention these for completeness, not to suggest them as alternatives. |
|
Date |
User |
Action |
Args |
2019-05-15 12:08:11 | steven.daprano | set | recipients:
+ steven.daprano, rhettinger, gregory.p.smith, mbussonn, pablogsal, remi.lapeyre |
2019-05-15 12:08:11 | steven.daprano | link | issue36906 messages |
2019-05-15 12:08:10 | steven.daprano | create | |
|