Thank you for the toolchain, I’m currently downloading it to test. As already mentioned a couple times the rules can be simplified by disallowing text after and before the starting/leading delimiters.
Allow single line tripled string """text""" Multi-lined text should always be between the delimiter lines. Therefore there is no need for an implicit leading new line or something like """\. The trailing new line is the artifact of the rule #3. Each line in between the delimiter lines produces an implicit new line if not disabled with an explicit backslash at the end of that line. (Last line produces the mentioned artifact in #2.) The backslash is also used for trailing precision if needed, however the cost is that the implicit new line is disabled and one would need to write \n\. The closing delimiter determines the indent for the current multi-line string literal, by calculating its indent-prefix from the start of that line to the delimiter itself. Each line in between the delimiters is stripped exactly like the calculated indent-prefix in #5. If it’s not possible, because of a mismatch of the spacing characters or a non-spacing character was found before the algorithm finished stripping the current line, a warning is emitted to fix the indent. (This rule covers literally everyones indent preferences, because it should not care if the ident is using spaces only, tabs only or a mix of them.) #5 and #7 also allows easy leading spacing precision, which was a tedious approach with continuation quotes. I think I pretty much covered everything here now. Let me know if I missed something. -- Adrian Zubarev Sent with Airmail Am 12. April 2017 um 21:08:19, John Holdsworth via swift-evolution (swift-evolution@swift.org) schrieb: Finally.. a new Xcode toolchain is available largely in sync with the proposal as is. (You need to restart Xcode after selecting the toolchain to restart SourceKit) I personally am undecided whether to remove the first line if it is empty. The new rules are more consistent but somehow less practical. A blank initial line is almost never what a user would want and I would tend towards removing it automatically. This is almost what a user would it expect it to do. I’m less sure the same applies to the trailing newline. If this is a syntax for multi-line strings, I'd argue that they should normally be complete lines - particularly since the final newline can so easily be escaped. let longstring = """\ Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod \ tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, \ quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.\ """ print( """\ Usage: myapp <options> Run myapp to do mything Options: -myoption - an option """ ) (An explicit “\n" in the string should never be stripped btw) Can we have a straw poll for the three alternatives: 1) Proposal as it stands - no magic removal of leading/training blank lines. 2) Removal of a leading blank line when indent stripping is being applied. 3) Removal of leading blank line and trailing newline when indent stripping is being applied. My vote is for the pragmatic path: 2) (The main intent of this revision was actually removing the link between how the string started and whether indent stripping was applied which was unnecessary.) On 12 Apr 2017, at 17:48, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote: Agree. I prefer the new rules over the old, but considering common use cases, stripping the leading and trailing newline makes for a more pleasant experience than not stripping either of them. I think that is generally worth prioritizing over a simpler algorithm or even accommodating more styles. Moreover, a user who wants a trailing or leading newline merely types an extra one if there is newline stripping, so no use cases are made difficult, only a very common one is made more ergonomic. _______________________________________________ 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
