Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

(Despite Ben's claims...) Are there no limits on interpolation? I don't see anything about that in the informal addendum to the undetailed proposal. Will multiline strings in interpolations in normal string literals enable them to lexically span multiple lines? Based on Swift 3.0.2 accepting

Re: [swift-evolution] [Review] SE-0168: Multi-Line String Literals

• What is your evaluation of the proposal? -1, for two reasons: (from https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034897.html and follow-up) First, having the same beginning and ending delimiter, with no continuation character, makes it very easy for a syntax

Re: [swift-evolution] 'Random' Improvements

Haha: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033482.html > > In general, I’d recommend against providing a default that we know won’t meet > everyone’s needs, > as randomness can have security properties. The same could be said of Hashable and even String

Re: [swift-evolution] multi-line string literals.

Can we try to enumerate the potential hazards and potential useful features associated with multi-line strings? Then perhaps you can judge various proposals based on them. Potential hazards: H1) Forgotten '+' (plus). This affects the current idiom where you could end up with part of your

Re: [swift-evolution] Disallowing unreachable code

>> On Mar 28, 2017, at 9:40 PM, Peter Dillinger >> wrote: >>> Agreed, we have the right design here. The go community has shown the >>> result of taking >>> a hard line on this, and it really hurts refactoring and other experimental >>> “pound out some >>> code”

Re: [swift-evolution] Disallowing unreachable code

> Agreed, we have the right design here. The go community has shown the result > of taking > a hard line on this, and it really hurts refactoring and other experimental > “pound out some > code” prototyping use cases. We use warnings for things that “should be > cleaned up before > code is

Re: [swift-evolution] Disallowing unreachable code

> -1, for all the reasons others have already explained. This unnecessarily > complicates the debugging process. If you ship code with warnings still in > it, that’s your own fault. All the obsolete/unfounded reasons? Please address my technical arguments directly, rather than in the

Re: [swift-evolution] Disallowing unreachable code

> To use a germane example, if unreachable code were always an error, a > programmer trying to > debug a problem wouldn't be able to short-circuit a function by just adding a > return; True, but > they'd also have to comment out the rest of the function. No, as you can do if (true) {

Re: [swift-evolution] Disallowing unreachable code

I should have clarified what I mean by "unreachable". I am referring to user code that is orphaned in a standard control flow graph construction, which does not perform any optimizations based on the values of expressions. The following has unreachable code: return 42; return -1; //

[swift-evolution] Disallowing unreachable code

I don't see anything directly relevant to this in the archives, and I haven't prepared a detailed proposal. But I'm raising the general idea because I recently criticized Swift 3 for allowing unreachable code in a blog post:

Re: [swift-evolution] Disallowing many expressions with unused result (@error_unused_result?)

> If I copy/paste your code (and add a definition for “trs”), Swift already > gives a warning: ... What version of Swift are you using? The first word of my subject is “disallowing” not “warning.” And I wrote, and you quoted, the following about compiler warnings: >> Part of my argument is

[swift-evolution] Disallowing many expressions with unused result (@error_unused_result?)

I recently criticized Swift 3 for allowing many expressions with no side effects as statements, in this blog post: https://blogs.synopsys.com/software-integrity/2017/03/24/swift-programming-language-design-part-2/ (search for "that expression"). I've seen some related discussion such as "Make