[swift-evolution] [Review] SE-0168: Multi-Line String Literals

[David Hart]

> On 6 Apr 2017, at 22:34, Haravikk via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 	• What is your evaluation of the proposal?
> 
> I'm a -1 for several reasons, mostly subjective but still. First thing is that I'm generally not comfortable with encouraging the use of multi-line strings at all. These are things that usually should be templated or localised, and personally I don't see what's inconvenient about concatenating on those occasions where you can't (or just don't want to); I'm actually of the opinion that this is the kind of thing that should be awkward and annoying, to encourage developers to think about what they're doing.

IMHO, there are plenty of uses for multi-line strings that are entire valid and acceptable. SQL queries is the example I encounter the most in my day-to-day work. And concatenating makes working with them very cumbersome.

> My second issue really is that, if the aim is simply to indent your multi-line string more nicely, then is this actually something that the language has to solve? I know we don't like to consider proposals purely from the perspective of what an IDE may, or may not, do, but this seems like a case where a good IDE could take:
> 
> let foo = "This is my
> multi-line
> text"
> 
> And display it visually to look like:
> 
> let foo = "This is my
> 	multi-line
> 	text"
> 
> This is basically what Xcode does for line-wrapped text right now. While it would mean people using more basic editors would still see the original, it's not really like that's a major problem.
> 
> Another alternative might be a compiler directive that is more explicit about what you want to do, for example:
> 
> let foo = #trimleft("
> 	This is my
> 		multi-line
> 	text
> ")
> 
> Here the directive would look at the text as a whole and see that all lines are indented by at least one tab, and so strip one tab from each line. There's probably a better name for the directive, but hopefully you hopefully get the idea, as this is much more explicit about what you want to do.
> 
> Also, one thing that really stands out with the proposal is how unwise the example is; the fact that the assertion relies on leading whitespace being stripped from the multi-line HTML makes it clear why things like this may not be a good idea, as if the code is edited to produce indented HTML then the assertion will fail, even if the HTML is still correct. The continuation quotes example makes this more obvious as it actually include some of the whitespace, so which is correct?
> 
> I don't want to seem too negative, I just think that whitespace stripping multi-line strings are a weird thing to want in a language. If an easier multi-line syntax has to be added then my preference would be for the alternative continuation quotes personally, as it's more explicit about what is included, though I still say there's nothing wrong with just doing the concatenation and newline characters IMO, as it's fully supported today and not really that much more burdensome to do (and it being a bit more difficult may be a good thing, as I say).
> 
>> 	• Is the problem being addressed significant enough to warrant a change to Swift?
> 
> Not really. We can already do multi-line by either putting newlines inside quotes and leaving out indentation, or by concatenating lines terminated with the new-line character. IMO these two existing options are enough as it is.
> 
>> 	• Does this proposal fit well with the feel and direction of Swift?
> 
> I'm not sure; in terms of simplicity I think that adding new syntax for multi-line strings is an unnecessary added complexity and something else to learn, and doesn't enable anything we can't already do fairly easily.
> 
>> 	• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> All of the proposed syntaxes are present in various languages, I've used many of them, and I know from my own bad habits that 99% of the time I shouldn't have 😏
> 
>> 	• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> Followed the discussion and re-read the proposal.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170406/2e6475a5/attachment.html>