> Am 13.04.2017 um 00:20 schrieb Brent Royal-Gordon <br...@architechies.com>: > > Wow, maybe I shouldn't have slept.
:-) > > Okay, let's deal with trailing newline first. I'm *very* confident that > trailing newlines should be kept by default. This opinion comes from lots of > practical experience with multiline string features in other languages. In > practice, if you're generating files in a line-oriented way, you're usually > generating them a line at a time. It's pretty rare that you want to generate > half a line and then add more to it in another statement; it's more likely > you'll interpolate the data. I'm not saying it doesn't happen, of course, but > it happens a lot less often than you would think just sitting by the fire, > drinking whiskey and musing over strings. > > I know that, if you're pushing for this feature, it's not satisfying to have > the answer be "trust me, it's not what you want". But trust me, it's not what > you want. > > Moving to the other end, I think we could do a leading newline strip *if* > we're willing to create multiline and non-multiline modes—that is, newlines > are _not allowed at all_ unless the opening delimiter ends its line and the > closing delimiter starts its line (modulo indentation). But I'm reluctant to > do that because, well, it's weird and complicated. I also get the feeling > that, if there's a single-line mode and a multi-line mode, we ought to treat > them as truly orthogonal features and allow `"`-delimited strings to use > multi-line mode, but I'm really not convinced that's a good idea. > > (Note, by the way, that heredocs—a *really* common multiline string > design—always strip the leading newline but not the trailing one.) > > Adrian cited this example, where I agree that you really don't want the > string to be on the same line as the leading delimiter: > > let myReallyLongXMLConstantName = """<?xml version="1.0"?> > <catalog> > <book id="bk101" empty=""> > <author>John Doe</author> > <title>XML Developer's > Guide</title> > <genre>Computer</genre> > <price>44.95</price> > </book> > </catalog>\ > """ > > But there are lots of places where it works fine. Is there a good reason to > force an additional newline in this? > > 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'?\ > “"" Yes, I think there is a good reason to force an additional newline in this: the beginnings of the line are not aligned otherwise or the editor would be required to create custom indentation based on the position of the leading "““ and whether it is followed by text or not (shudder). To summarize: 1. I support Adrian’s idea of requiring that the opening triple quote may not be followed by text if and only if the closing triple quote is not preceded by text, i.e. only the following two forms are allowed: a. single line form """text"“" b. multiline form (whitespace allowed before each line, of course) "“"↵ text↵ ""“ 2. Furthermore I would strip the first newline and keep the last newline. As Adrian put it quite well: each line between the triple quotes is part of the string and ends with a newline (except if ending with a backslash). This is an easy mental model and aligns with the most common use cases. "“"↵ text↵ ""“ would therefore be equal to """text↵"“" 3. In addition I support Adrian’s idea of stripping trailing whitespace from the content (except newlines). To keep trailing whitespace it must be ended with a backslash and thereby made visible. That is similar to my idea of always using \n for the newlines within a multiline string which has already been incorporated into the proposal (thanks for that!). -Thorsten > > I mean, we certainly could, but I'm not convinced we should. At least, not > yet. > > In any case, trailing newline definitely stays. Leading newline, I'm still > thinking about. > > As for other things: > > * I see zero reason to fiddle with trailing whitespace. If it's there, it > might be significant or it might not be. If we strip it by default and we > shouldn't, the developer has no way to protect it. Let's trust the developer. > (And their tooling—Xcode, I believe Git, and most linters already have > trailing whitespace features. We don't need them too.) > > * Somebody asked about `"""`-delimited heredocs. I think it's a pretty > syntax, but it's not compatible with single-line use of `"""`, and I think > that's probably more important. We can always add heredocs in another way if > we decide we want them. (I think `#to(END)` is another very Swifty syntax we > could use for heredocs--less lightweight, but it gives us a Google-able > keyword.) > > * Literal spaces and tabs cannot be backslashed. This is really important > because, if you see a backslash after the last visible character in a line, > you can't tell just by looking whether the next character is a space, tab, or > newline. So the solution is, if it's not a newline, it's not valid at all. > > I'll respond to Jarod separately. > >> On Apr 12, 2017, at 12:07 PM, John Holdsworth <m...@johnholdsworth.com >> <mailto:m...@johnholdsworth.com>> wrote: >> >> Finally.. a new Xcode toolchain >> <http://johnholdsworth.com/swift-LOCAL-2017-04-12-a-osx.tar.gz> 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 <mailto: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. >> > > -- > Brent Royal-Gordon > Architechies >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
