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. Single-line expression. Multi-line expression with no text directly after/before the delimiters (not even a backslash like """\). Each line adds a new line (multi-line). Disabling with the backslash. Emitting a warning when trailing whitespaces are present but no \ is found at the end of the same line. + Fix-it with \n\ Not sure about the indent algorithm (I prefer the calculation of the prefix). 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 ([email protected]) schrieb: On Apr 15, 2017, at 3:28 PM, Thorsten Seitz <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
