Received on the -comments list. Summary: another plea for “just do what Swift does”.
My response: The approach of “just do what language X does” is intrinsically irresponsible; nearly every feature of every language is conditioned by other features of that language. Instead, the game is to learn from how other languages do things, assess the tradeoffs they’ve chosen (explicitly and implicitly), and ask what can be applied to the constraints of the language we have and user expectations within the community we have. That said, there's lots to learn from Swift did (note that this aligns strongly with John’s “strong interruptor” theory). Similarly aligned with John’s point from the other day, is that raw/non-raw is not a binary, but a spectrum, and in that, there may be a path to seeing the two in a unified framework, rather than two alternatives. This is a useful direction to explore, and, if we go this way, we should drop the “raw” terminology by the wayside, because its both pulls the design center in another direction, and is a confusing way to describe the feature. (Kotlin has similarly adopted the “raw” terminology in a distinctly non-raw way, which is similarly unfortunate.). All that said, purely for purposes of making forward progress, I'm declaring a temporary moratorium on raw-ness and escaping until we work out the 1/1a story for multi-line strings. We’re deep in Jim’s “hangry” territory, and we need to eat something before we dive down that rathole. > Begin forwarded message: > > From: Fred Curts <fred.cu...@icloud.com> > Subject: String reboot (plain text) > Date: March 18, 2019 at 7:43:56 AM EDT > To: amber-spec-comme...@openjdk.java.net > > Let's do a thought experiment: If Java literally adopted Swift's string > literals, there would be no old/new or raw/non-raw distinctions. There would > just be single line and multiline strings with customizable string > delimiters. (Swift's "raw string" terminology is unfortunate.) A truly raw > string literal would be easy enough to simulate with a highly customized > string delimiter (which, importantly, also gives a highly customized escape > sequence) and unindented closing delimiter. String interpolation could be > added later (even for single line strings) because it's based on the existing > (now customizable) escape sequence. What's not to like here? > > In my view, Swift demonstrates that customizable string delimiters (which > also affect escape sequences) make a raw/non-raw distinction unnecessary. > (Note that this has nothing to do with coupling orthogonal features.) I have > yet to hit a case where Swift's string literals prove inadequate in practice. > > -Fred > > On Wed, Mar 13, 2019 at 12:57 PM Brian Goetz <brian.goetz at oracle.com> > wrote: > >> To the “indent is good enough” point: Auto reflow is a disaster when >> applied to mixed spaces and tabs; while in general one should avoid this, I >> cannot rule out the possibility that someone might actually want to embed >> such a snippet; in that case, truly raw strings are an option. If we take >> away truly raw, now they just have two bad approximations. >
