An alternative proposal re: Raw string literals -- restarting the discussion
fredt at users.sourceforge.net
Wed Jan 2 19:55:26 UTC 2019
Proposal In response to the post by Brian Goetz in amber-spec-experts list on 2019-01-02:
1. HTML and XML can contain blocks marked up as `<code> </code>` where the contents and the line breaks between the tags are preserved verbatim. SQL has comment lines starting with `--` which must be preserved and not mixed with the next line. So the languages that are assumed will be embedded do indeed need real raw strings. And future languages in the next 20 years may need the rawness. Another type of content that is very likely to be used is strings containing the equivalent of a Java properties file or a Java resource file (containing a collection of String definitions) embedded in Java source code.
2. I can think of an alternative raw String declaration such as `CharSequence s = CharSequence.contentsOfNext(int lineCount)` in which the lineCount number of lines following the declaration are treated as the contents of the string. The `toString()` method of the CharSequence must be called as the first Java statement following the raw string block. See point 4 for justification.
3. The only possible ambiguity in the raw string declarations is: which character is used as end of line? A rule can be imposed that the line-feed `\n` character is used as end of line by the compiler even when the Java source file is written or compiled in a Windows environment. If the user requires a different line-end character, they can simply replace it after the raw String instantiation. Similarly, they can remove the last line-feed if it is not desired.
4. It may be argued that the `lineCount` may be too small or too large for the intended raw string. The too small situation is highly unlikely as the Java source will not compile in most cases and the IDE will show the error. The too large situation can be prevented by treating the `CharSequence s` as unmaterialized until its toString() method is called. Therefore a call to `s.toString()` must follow immediately after the raw string block.
5. This proposals allows real raw strings declarations in Java source files. Any un-escaping or other transformation can be applied to the String after instantiation. It therefore fulfills all stated use-cases as well as many others.
More information about the amber-spec-observers