(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
• 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 hi
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 concat
> func getRandom(_ min: Int, _ max: Int) -> Int {
>let diff = max - min + 1
>
>#if os(Linux)
>return min + Int(random() % diff)
> ...
Implementation detail: non-uniformity mistakes of the past should not be
repeated. http://stackoverflow.com/a/6852396/454544 (Timed out on
> H3) No recovery for tokenization / syntax highlighting. IMHO, this is the
> big drawback of Python-style """ strings.
A key way this manifests is while typing your program. When you type the
opening """, the rest of the text in the file is going to be "inverted" between
code and multiline s
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 in
>> 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” prototyping use cases. We use
> 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 com
> -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 (potentia
> 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
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; // unrea
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:
https://blogs.synopsys.com/software-integrity/2017/03/24/swift-program
> 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 tha
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
14 matches
Mail list logo
