> > - Multi-line-ness and raw-ness are orthogonal concepts. > > Is that true, as stated? I would have said that any support for rawness > automatically gives you support for multi-line-ness by nature, because a > newline character becomes literal. That doesn't seem like orthogonality.
My claim is that this is a shortcut that skips over the inherent orthogonality, and in the process, misses out on some useful improvements. It’s a shortcut that works (other languages have gone there), but we lose something by compressing the two features into one. For example, we miss out on the opportunity to do text reflow on non-raw-ML strings and not do it on raw-ML strings (I don’t think we can really justify doing it automatically on raw strings; that’s not what raw means.) So if we compress the two concepts, we have to give up automatically on automatic reflow, even though it is worth considering. > I say this because it's the reason I was always completely fine with the fact > we were talking only about a "raw" feature and not two independent features. > The proposal as it was published months ago would have done somewhere close > to 100% of what our codebase needs... if only we could have settled how to > get indentation stripping. We had options for how that could be done in a > reasonably learnable way, and of course with the strict requirement that the > "I only care about rawness" users are unaffected. I know this opinion is not > shared, but it seemed to me that it was only our discomfort with writing the > stripping behavior into the language spec, and nothing else, that stopped us > from having a great solution. I would phrase this as: “raw is often an acceptable substitute for ML.” > > Now, maybe we're still a little hungry, and the above doesn't help with those > strings that are most polluted by escapes, such as regular expressions. So, > we might additionally order the ability to layer a way to say "no escape > mangling" atop both our " strings and our """ strings. Jim proposes we > use a delimiter of \".."\ for such strings (\""" ... """\ for the multi-line > version). This has a nice connotation; it is as if the backslash is > “distributed over” the whole string. > > This is the part that concerns me a lot. I think that adding *two* new > string-literal features that can be used separately or together is putting > the language in a much more complex state. If we reached State A (above) I > would feel much better about stopping there than coming here. And that’s a valid choice! State A was placed first because it is simple, effective, and might well be enough; the rest of the discussions is an exercise in incremental costs and incremental benefits.
