> Le 16 mai 2017 à 17:31, Xiaodi Wu <[email protected]> a écrit : > > On Tue, May 16, 2017 at 8:01 AM, Gwendal Roué <[email protected] > <mailto:[email protected]>> wrote: > Xiaodi Wu, your opposition has been recorded. You don't buy the Motivation > section. Other people here do, definitely. > > I think you make some insightful comments below. But again, to clarify, I am > not voicing support or opposition to the ideas themselves. >
> I am objecting that this pitch contains mostly ideas discussed previously and > amply, and which have been formally considered and rejected. _Whether or not > you buy the motivation for doing so_, it is--as a matter of etiquette if > nothing else--not appropriate to make repeated pitches every few weeks. As I > wrote earlier, few (if any) people would volunteer their time and effort to > bring up thoughtful points about an upcoming decision if the same discussion > is simply going to repeat itself two weeks after the decision has been made. You did very kindly quote the rejection reasons. This is a work effort that the proposal authors should take seriously. Everybody knows how difficult it is to find a past message in swift-evolution :-) The core team has left some room for improvement. They talk about non-explicit "subtleties", and future "additive features". I don't see any etiquette violation here. > Therefore, I am claiming that even if some believe that this is the best idea > ever conceived, and even if minor changes to the rationale or design are > made, it should as a matter of principle not be the subject of further > discussion on this list _because it has already been rejected_. To do so > would undermine accepted norms which are important to encourage thoughtful > and timely participation. Like you, I want any further work to build on top of SE-0168, which has been accepted. There is no matter for a fileprivate drama here. The new proposal needs some focus: we should give some time to the authors. Gwendal > > > > > Le 15 mai 2017 à 23:52, Xiaodi Wu via swift-evolution > > <[email protected] <mailto:[email protected]>> a écrit : > > > > I'm quite sure it means this: As with all parts of Swift, a decision can be > > re-considered if implementation difficulties are found, or if new insights > > arise from extended use. Because these features are additive, rejecting > > them now does not mean that source compatibility requirements would make > > such re-consideration impossible--if they are to be re-considered in the > > future. Until such time as a fit justification is found to bring the > > current decision into question, the decision of the core team is that these > > proposed features are rejected from inclusion in Swift. > > On Mon, May 15, 2017 at 16:28 David Hart <[email protected] > > <mailto:[email protected]>> wrote: > >> On 14 May 2017, at 03:55, Xiaodi Wu <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> On Sat, May 13, 2017 at 1:42 AM, David Hart <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >>> On 12 May 2017, at 23:14, Xiaodi Wu <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> I feel like a broken record: Of the three proposed components of the > >>> proposed solution, two were amply considered by the community and the > >>> core team in SE-0168. The decision has already been made _not_ to > >>> implement these ideas at this time. > >> > >> Can you provide me with quote from the Core Team that it should not be > >> implemented at this time? I have troubles finding it. > >> > >>> Significant defects discovered after the fact during implementation or > >>> new insights after extensive usage can prompt revisiting the decision, > >>> but that is not the case here: implementation did not require further > >>> clarification and the feature has only just landed on master. We simply > >>> cannot revisit topics willy-nilly. The process simply cannot work that > >>> way: few have the time and energy to offer their fullest consideration > >>> the first time round, and no one would be willing to do that if it means > >>> that the same topic will be revisited one month later. > >> > >> The concerns summarised in this proposal were only heavily discussed after > >> the acceptance of multi-line strings. Therefore, there is a great chance > >> that they were not discussed by the Core Team. We feel obliged to put this > >> proposal forward to formalise those issues. > >> > >> > >> [1] > >> > >> Your draft proposes to '[d]ivorce the `"""` delimiter from [...] > >> multi-line syntax' in order to allow `"""long strings"""` to be valid > >> syntax. > >> > >> SE-0168 proposed 'a single simple syntax for inclusion: """long > >> strings"""`, explicitly permitting that syntax. > >> > >> The core team, after considering SE-0168, deliberately rejected that > >> feature for Swift 4. They wrote that they 'acknowledge[] that single-line > >> triple quoted strings have other uses in other languages, [...] but > >> supporting that alongside the indentation-stripping behavior leads to a > >> lot of subtlety, and there could be other solutions to the escaping > >> problem down the line, such as raw strings.' They concluded that: 'If > >> nothing else, single-line triple quoted strings can be considered later as > >> an additive feature.' > >> > >> [2] > >> > >> Your draft proposes to 'support escaping newlines in multi-line strings > >> with a trailing `\`'. > >> > >> The core team, after considering SE-0168, acknowledged that '[d]iscussion > >> on the list raised the idea of allowing a line to end with \ to "escape" > >> the newline and elide it from the value of the literal.' They deliberately > >> rejected that feature for Swift 4, reasoning that '[they] had concerns > >> about only allowing that inside multi-line literals and felt that that > >> could also be considered later as an additive feature.' > >> > >> > >> If someone from the Core Team lets us know this is definitely out of scope > >> for Swift 4, we’ll be happy to bring it back once discussion for Swift 5 > >> starts. > >> > >> > >> Not being on the core team, I can't tell you what's definitely out of > >> scope, but I'm pretty sure discussing something "down the line" and > >> "later" don't mean revisiting a topic 22 days after the original proposal > >> is modified and 16 days after it's implemented, but rather in a future > >> version of Swift, after users have been able to try and gain experience > >> with the approved design. > > > > Thanks for the references! Indeed, those specific points were discussed but > > I’m not sure what they mean by "can be considered later as an additive > > feature”. I’m not so certain it necessarily pushes it back to a future > > version of Swift. Nonetheless, the other points in the proposal don’t seem > > to have been discussed. > > > >>> On Fri, May 12, 2017 at 15:51 David Hart via swift-evolution > >>> <[email protected] <mailto:[email protected]>> wrote: > >>> Hi swift-evolution, > >>> > >>> Adrian Zubarev and I have discussed several issues with string literals > >>> still unresolved after the multi-line string literals proposals and we > >>> believe that they are important enough to address for Swift 4. Here is > >>> the pitch for our proposal. > >>> > >>> Please let us know what you think: > >>> > >>> https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md > >>> > >>> <https://github.com/hartbit/swift-evolution/blob/literal-string-improvements/proposals/XXXX-improve-string-literals.md> > >>> > >>> Improve String Literals > >>> > >>> • Proposal: SE-XXXX > >>> • Authors: David Hart, Adrian Zubarev > >>> • Review Manager: TBD > >>> • Status: TBD > >>> Introduction > >>> > >>> This proposal builds on top the new features of SE-0168 Multi-Line String > >>> Literals by widening the use-cases for unescaped double-quotes and > >>> resolving certain issues around long lines in single and multi-line > >>> string literals. > >>> > >>> Motivation > >>> > >>> In Swift 3, String literals have three pain points: > >>> > >>> • Strings containing double-quotes > >>> • Multi-line strings > >>> • Long single-line strings > >>> Proposal SE-0168 fixed the two first problems with the same syntax. > >>> Unfortunately, while an improvement on Swift 3, several problems remain: > >>> > >>> • Long single-line strings still require the less than ideal > >>> concatenation syntax: > >>> Some project styles (like the Standard Library) mandate a maximum line > >>> length, requiring long single-line strings to be hard-wrapped. This still > >>> requires odd solutions: > >>> > >>> assert(condition, "This is a long assertion message that requires " + > >>> > >>> > >>> "string concatenation when the project style enforces maximum line " + > >>> > >>> > >>> "lengths") > >>> • Long lines in a multi-line strings can't be manually wrapped: > >>> let markdown = """ > >>> # Title > >>> > >>> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer > >>> elementum commodo sem, a congue orci porta sit amet. Duis facilisis, est > >>> et vehicula congue, turpis dui ultricies nunc, ut elementum quam elit nec > >>> felis. Integer aliquam id risus nec laoreet. Vivamus vitae odio sit amet > >>> quam iaculis fermentum nec sed neque. > >>> > >>> ## Subtitle > >>> > >>> Cras et nibh velit. Praesent eleifend sagittis quam, pellentesque > >>> lobortis lectus commodo vel. Vivamus suscipit, nulla quis blandit > >>> ullamcorper, velit neque euismod nibh, nec blandit mi diam molestie ex. > >>> Cras porttitor, est sed pharetra interdum, ipsum mauris viverra quam, sit > >>> amet eleifend purus elit sit amet odio. > >>> """ > >>> • Short strings containing double-quotes have to use the multi-line > >>> syntax to benefit from unescaped double-quotes: > >>> print(""" > >>> { "success": false, "error": "Wrong parameter" } > >>> """) > >>> Proposed solution > >>> > >>> By implementing multi-line string literals and support for unescaped > >>> double-quotes with the same syntax, SE-0168 has made those features > >>> unusable on their own. By dissociating them and supporting two extra > >>> syntax features, we can solve all the above problems: > >>> > >>> Divorce the """ delimiter from the multi-line syntax and have them only > >>> support unescaped double-quotes > >>> > >>> The change allows us to express short strings containing double-quotes > >>> without resorting to the multi-line syntax: > >>> > >>> print("""{ "success": false, "error": "Wrong parameter" }""") > >>> As a consequence, multi-line strings are now only defined by a newline > >>> following the leading delimiter and the whitespace preceeding the > >>> trailing delimiter. They gain support for " delimiters, which has the > >>> nice advantage of saving a few characters in multi-line strings which are > >>> known to never contain double-quotes: > >>> > >>> print(""" > >>> Triple " > >>> are still valid delimiters > >>> > >>> """) > >>> > >>> query(" > >>> > >>> SELECT 'name' > >>> FROM 'people' > >>> WHERE age > >>> > 20 > >>> > >>> > >>> ") > >>> Support escaping newlines in multi-line strings with a trailing \ > >>> > >>> This change allows hard-wrapping long lines in multi-line strings. They > >>> also have the added benefit of making trailing white-space at the end of > >>> source-code lines explicit. > >>> > >>> let markdown = """ > >>> # Title > >>> > >>> Lorem ipsum dolor sit amet, consectetur adipiscing elit. Integer \ > >>> elementum commodo sem, a congue orci porta sit amet. Duis facilisis, > >>> est \ > >>> et vehicula congue, turpis dui ultricies nunc, ut elementum quam elit > >>> nec \ > >>> felis. Integer aliquam id risus nec laoreet. Vivamus vitae odio sit > >>> amet \ > >>> quam iaculis fermentum nec sed neque. > >>> > >>> ## Subtitle > >>> > >>> Cras et nibh velit. Praesent eleifend sagittis quam, pellentesque \ > >>> lobortis lectus commodo vel. Vivamus suscipit, nulla quis blandit \ > >>> ullamcorper, velit neque euismod nibh, nec blandit mi diam molestie \ > >>> ex. Cras porttitor, est sed pharetra interdum, ipsum mauris viverra \ > >>> quam, sit amet eleifend purus elit sit amet odio. > >>> """ > >>> Adopt the C/Objective-C syntax that concatenates single-line strings > >>> > >>> This change will be familiar to C developers and provides a cleaner and > >>> more performant solution for long single-line strings: > >>> > >>> assert(condition, "This is a long assertion message that flows " > >>> > >>> > >>> "from one line to the next without requiring the concatenation " > >>> > >>> > >>> "operator" > >>> ) > >>> > >>> > >>> assert(condition, """This is another "single-line" message that """ > >>> > >>> > >>> """supports up to two double-quotes (" and "") without any """ > >>> """escaping""") > >>> Source compatibility > >>> > >>> This feature is purely additive; it has no effect on source compatibility. > >>> > >>> Effect on ABI stability > >>> > >>> This feature is purely additive; it has no effect on ABI stability. > >>> > >>> Effect on API resilience > >>> > >>> This feature is purely additive; it has no effect on API resilience. > >>> > >>> Alternatives considered > >>> > >>> A different syntax for supporting long single-line strings was discussed > >>> where ending delimiters were replaced with the \escaping character, > >>> mirroring their use in multi-line strings: > >>> > >>> assert(condition, "This is a long assertion message that flows \ > >>> " > >>> from one line to the next without requiring the concatenation \ > >>> > >>> "operator" > >>> ) > >>> > >>> > >>> assert(condition, """This is another "single-line" message that \ > >>> """supports up to two double-quotes (" and "") without any \ > >>> """escaping""") > >>> That syntax saved two characters per line in strings with """ delimiters > >>> but had several disadvantages: > >>> > >>> • It loses the familiarity with C syntax > >>> • It introduces an asymmetry between the last line and those above > >>> • It does not do any actual escaping, introducing developer ambiguity > >>> with their use in multi-line literals > >>> > >>> _______________________________________________ > >>> swift-evolution mailing list > >>> [email protected] <mailto:[email protected]> > >>> https://lists.swift.org/mailman/listinfo/swift-evolution > >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > >> > >> > > _______________________________________________ > > swift-evolution mailing list > > [email protected] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
