> On 6 Apr 2017, at 22:34, Haravikk via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On 6 Apr 2017, at 20:35, Joe Groff via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
