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

[Vladimir.S]

On 16.04.2017 0:22, Adrian Zubarev via swift-evolution wrote:
> Hi guys, I am, and also my English is, at my most limit fighting in this 
> conversation. ;-)
> 
> I would not support, v1 v2 and v3 at all and would wish these options to be 
> completely banned for a nice and simple model, even if all of the options can be 
> implemented and might look OKAY for some specific examples. IMHO these mixed options 
> overcomplicating the model.
> 
> I’d love to see the authors revision the proposal tackling the simple model I 
> initially pushed forward, where I revised my personal opinion about the last content 
> line, but most of you felt comfortable with.
> 
>  1. Single-line expression.
>  2. Multi-line expression with no text directly after/before the delimiters (not even
>     a backslash like |"""\|).
>  3. Each line adds a new line (multi-line).
>  4. Disabling with the backslash.
>  5. Emitting a warning when trailing whitespaces are present but no |\| is found at
>     the end of the same line. + Fix-it with |\n\|
>  6. Not sure about the indent algorithm (I prefer the calculation of the prefix).

My +1. Easy to remember and follow rules, no un-needed confusion points, nice looking 
syntax for common cases but still flexible enough for other use-cases.

About indent algorithm.. IMO we need the ability to have leading whitespaces for 
*each* multi-line's line, so in such case we need the ability to specify the number 
of whitespaces we want to keep for each, so for now the best option is determinate 
the number of leading whitespaces by position of closing delimiter """.


> 
> I also would be pleased when the authors could put the model I would prefer in the 
> alternative section, so that the majority and the core team could have the chance to 
> decide for the better one during the next review run.
> 
> Thanks to everyone for tackling the topic forward. ;)
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 15. April 2017 um 21:56:27, Ricardo Parada (rparada at mac.com 
> <mailto:rparada at mac.com>) schrieb:
> 
>>
>>> On Apr 15, 2017, at 3:28 PM, Thorsten Seitz <tseitz42 at icloud.com 
>>> <mailto:tseitz42 at icloud.com>> wrote:
>>>
>>>> Here is another example:
>>>>
>>>> case .isExprSameType(let from, let to):
>>>> return """checking a value with optional type \(*from*)\
>>>> against dynamic type\(*to*) \
>>>> succeeds whenever the value is non-'nil'; \
>>>> did you mean to use '!= nil'?\
>>>> """
>>>>
>>>
>>> This only works because the lines have been indented by hand to match correctly 
>>> which would not be the case with standard indentation used in a code editor which 
>>> is a fixed multiple of spaces or tabs: the example had to add 2 spaces to the 2 
>>> tabs in this example to fix the indentation (requiring 8-space-tabs). In reality 
>>> the example would look like follows (assuming 4-space-indentation but the problem 
>>> is the same for other indentations):
>>>
>>> case .isExprSameType(let from, let to):
>>>     return """checking a value with optional type \(*from*)\
>>>         against dynamic type\(*to*) \
>>>   succeeds whenever the value is non-'nil'; \
>>>   did you mean to use '!= nil'?\
>>> """
>>
>> That is perfectly fine too. I don't find this style confusing.  The 2nd, 3rd and 
>> 4th lines are stripped of their indentation according to the closing delimiter. And 
>> that is it.
>>
>>>> I personally do not find this style confusing at all.
>>>
>>> The confusion arises over the leading newline: why does text directly following 
>>> the opening triple quote have a newline while an empty line after the opening 
>>> triple quote does not have a newline?
>>
>> I think it is a good thing to have *the* *option* to start the line of text 
>> immediately after the opening delimiter or on the next line.
>>
>> Regards,
>> Ricardo
>>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>