> • using the default string literal recognition mechanism binds us to > have to ‘wait’ a bit in order to figure which kind of string literal we are > dealing with (single/multi line)
Part of the idea of the continuation quotes proposal is that there *is* no distinction between a single-line literal and a multi-line literal. There are just string literals, which may include one line or many. And in general, part of the advantage of this proposal is precisely that it has such low impact on the parser and lexer, and the grammar more generally. It is currently illegal to open a string and fail to close it on the same line, so we are just giving that obviously illegal construct an interpretation. By extending the existing feature, we get a whole lot of stuff for free: * We don't have to worry about whether `|>` or `@|` or whatever construct you end up using might, in some place where you could otherwise use a string literal, be confusable with some other construct. * We don't have to worry about whether obscure corners of the language, like the string parameters to `@available`, support multiline string literals (they do, automatically). * We don't have to do a huge amount of redesigning in the lexer, and I doubt we'll have to touch the parser at all (the prototype doesn't). It seems a bit backwards to propose we introduce a separate path for lexing multiline strings, and then complain that one of the proposals on the table makes it difficult to tell which path you should take, when the proposal in question is specifically designed to make having a separate path unnecessary. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
