Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Jacob Bandes-Storch via swift-evolution]

I hope my replies aren't too curt — I don't want to pick a fight (any more
than I did by starting this topic), but to explore how Discourse can serve
these use cases. Feel free to re-rebut.

On Mon, Aug 1, 2016 at 3:03 PM, Brent Royal-Gordon 
wrote:

>
> I don't think enough has been said in favor of mailing lists. Some
> advantages for them:
>
> 1. Available on every platform.
>
Browsers too.


>
> 2. Performant on every platform. (Discourse, for instance, struggles on
> Android.)
>
Browsers are heavily tuned for performance, and Discourse is a relatively
lightweight site. If you prefer the performance of your email client,
there's mailing list mode.


> 3. Native on every platform.
>
Browsers too.


>
> 4. Based on open standards with multiple implementations.
>
Browsers too. You may argue that the forum itself is too centralized, but
Mailman is necessarily centralized too.

And this isn't always a positive: formatting of styled, quoted, and even
plain text is quite varied among email clients, so popular threads often
end up looking like huge messes.


>
> 5. Does not require you to proactively check swift-evolution.
>
Email notification settings, or full-on mailing list mode, or RSS, can
solve this.


> 6. Supports offline reading and drafting.
>
Mailing list mode or RSS / reply-by-email.


> 7. Supports clients with alternate feature sets.
>
Discourse has RSS feeds and JSON APIs.


>
> 8. Supports bot clients for both sending (like the CI bot) and receiving
> (like Gmane).
>
Discourse has an API
 which can
be used for posting. It also supports bot-like plugins
 which can
respond to various events, although I imagine that requires self-hosting.
External bots interested in receiving would probably need to poll RSS, or
just make use of mailing list mode as a receive hook.


> 9. Supports user-specific automatic filtering.
>
Topics and categories in Discourse each support a range of notification
options from "watching" to "muted". My understanding is that these settings
are respected by mailing list mode.


>
> 10. Users can privately annotate messages.
>
Discourse has "bookmarks", basically a way of saving individual
posts/replies for yourself. Users can also send themselves private messages

for
note-taking purposes.


>
> 11. Drafts and private messages are not visible to any central
> administrator.
>
I'm not sure whether Discourse drafts are saved on the server. Moderators
are restricted from viewing private messages
.
Of course, you can always contact someone via other means.


> 12. History is stored in a distributed fashion; there is no single point
> of failure that could wipe out swift-evolution's history.
>
This is a fair point. But:
- The Git repository of proposals is distributed.
- Discourse is as easily backed up as any other computer system:
https://meta.discourse.org/t/configure-automatic-backups-for-discourse/14855
- Users who would like a low-fidelity local copy for themselves can enable
mailing list mode.
- Anyone is free to access/archive publicly accessible content using the
APIs.


>
> 13. Usually the medium of choice for large-scale, long-running open source
> projects.
>

Is that just because people already know how to use email? Is it because
the projects are so long-running that email was the best/only choice when
they started? I'm not sure anyone has done real academic research on the
use of mailing lists in open source projects. If someone can find any, I'd
be interested to read it.


>
> I could probably go on, but I'll stop here for now.
>
> I would love to have a great web archive for swift-evolution—something
> with a really solid search function, good threading, and most of the other
> niceties of forums. It'd even be nice to have an upvote feature. But these
> are all things that you could do without taking swift-evolution off of
> email.


This seems like status quo bias to me. It's just as valid to *start* with a
great forum system, and build any desirable additional features on top, as
it is to start with a mailing list and build additional features on top.
(Discourse being open-source is a pretty big advantage in terms of the
ability to add features.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

[Chris Lattner via swift-evolution]

Great, thanks!  (and thanks to Roman for fixing it already)

-Chris

> On Aug 2, 2016, at 10:29 PM, Xiaodi Wu  wrote:
> 
> SR-2247. Fixed by Roman Levenstein with PR #3924, which is already merged.
> 
> I've yet to test myself because the toolchain isn't building right on my 
> machine (lldb...) :/
> On Wed, Aug 3, 2016 at 00:19 Chris Lattner  > wrote:
> Awesome, thanks!  What is the bug #?  
> 
> -Chris
> 
>> On Aug 2, 2016, at 10:17 PM, Xiaodi Wu > > wrote:
>> 
>> Agreed! The bug has been filed, looked at by the wonderful people over at 
>> your HQ, and resolved--all faster than I can get the new toolchain to 
>> compile.
>> 
>> It looks like the operators && and || were missing a transparent annotation. 
>> I wonder if such issues are worth testing more systematically for primitive 
>> numeric types, and if so, how that might be done.
>> On Tue, Aug 2, 2016 at 22:29 Chris Lattner > > wrote:
>> If you see such a drastic slowdown, then tat sounds like a critical 
>> regression that you found in the latest beta.  We would really appreciate a 
>> bug report (radar or jira) with a testcase!
>> 
>> 
>> -Chris
>> 
>> On Aug 2, 2016, at 7:38 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>>> I'd like to echo Muse's point. Accelerate is no solution: it's not 
>>> available on Linux (and cross-platform numerics is very much essential for 
>>> the sciences--I assume engineering and finance as well); moreover, it 
>>> doesn't solve the issue of, as you point out, other kinds of math.
>>> 
>>> The appeal to me of Swift was that it promised a memory-safe-by-default 
>>> systems programming language, a compiled language with performance that can 
>>> be in the same ballpark as C. So while specialized libraries like BLAS can 
>>> speed up matrix algebra considerably, IMO, the same kinds of math that are 
>>> done in C or Go or Rust without calling BLAS should perform roughly 
>>> equivalently when ported to Swift. That it doesn't should be a bug, and the 
>>> workaround shouldn't have to be dropping down to or calling out to 
>>> libraries written in C or Fortran.
>>> 
>>> Recently, I discovered that a straightforward numerics algorithm that only 
>>> adds, divides, multiplies, and compares floating point values slowed down 
>>> five to ten *times* between preview 3 and preview 4. This was stunning--and 
>>> if performance ever was comparable to C before (I didn't check for this 
>>> particular function), I know for sure that it isn't anymore! Although I'm 
>>> confident that the underlying cause will be found, it does raise questions 
>>> as to the continued wisdom of writing even somewhat performance-sensitive 
>>> math in Swift.
>>> On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution 
>>> > wrote:
>>> Well, it depends on what kind of Math you’re trying to do. The Accelerate 
>>> framework is available if you need performance.
>>> 
>>> Saagar Jha
>>> 
>>> 
>>> 
 On Aug 1, 2016, at 18:01, Muse M via swift-evolution 
 > wrote:
 
 Have always wonder why Maths in Swift is slower than C and Go, it should 
 be address with priority if Swift is to be adopt for engineering, 
 financial and science industry.
 
 On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
 > wrote:
 See 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
  
 
 
 From what I understand, the discussion should stay focused on the main 
 topics for Swift 4 that Chris highlighted in 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
  
 
 
 I had several ideas in mind, but am postponing them for Swift 5, seeing 
 the schedule...
 
 
> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
> > wrote:
> 
> It was stated that 27th of July was the last date for proposal 
> acceptance, 29th of July was the last day for implementation, and 1th of 
> August should be the starting day of Swift 3.1-related discussions.
> Am I right? Should we begin?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

Re: [swift-evolution] Swift 3.1 discussions, go?

[Xiaodi Wu via swift-evolution]

Agreed! The bug has been filed, looked at by the wonderful people over at
your HQ, and resolved--all faster than I can get the new toolchain to
compile.

It looks like the operators && and || were missing a transparent
annotation. I wonder if such issues are worth testing more systematically
for primitive numeric types, and if so, how that might be done.
On Tue, Aug 2, 2016 at 22:29 Chris Lattner  wrote:

> If you see such a drastic slowdown, then tat sounds like a critical
> regression that you found in the latest beta.  We would really appreciate a
> bug report (radar or jira) with a testcase!
>
>
> -Chris
>
> On Aug 2, 2016, at 7:38 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'd like to echo Muse's point. Accelerate is no solution: it's not
> available on Linux (and cross-platform numerics is very much essential for
> the sciences--I assume engineering and finance as well); moreover, it
> doesn't solve the issue of, as you point out, other kinds of math.
>
> The appeal to me of Swift was that it promised a memory-safe-by-default
> systems programming language, a compiled language with performance that can
> be in the same ballpark as C. So while specialized libraries like BLAS can
> speed up matrix algebra considerably, IMO, the same kinds of math that are
> done in C or Go or Rust without calling BLAS should perform roughly
> equivalently when ported to Swift. That it doesn't should be a bug, and the
> workaround shouldn't have to be dropping down to or calling out to
> libraries written in C or Fortran.
>
> Recently, I discovered that a straightforward numerics algorithm that only
> adds, divides, multiplies, and compares floating point values slowed down
> five to ten *times* between preview 3 and preview 4. This was stunning--and
> if performance ever was comparable to C before (I didn't check for this
> particular function), I know for sure that it isn't anymore! Although I'm
> confident that the underlying cause will be found, it does raise questions
> as to the continued wisdom of writing even somewhat performance-sensitive
> math in Swift.
> On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Well, it depends on what kind of Math you’re trying to do. The Accelerate
>> framework is available if you need performance.
>>
>> Saagar Jha
>>
>>
>>
>> On Aug 1, 2016, at 18:01, Muse M via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Have always wonder why Maths in Swift is slower than C and Go, it should
>> be address with priority if Swift is to be adopt for engineering, financial
>> and science industry.
>>
>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> See
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>>
>>> From what I understand, the discussion should stay focused on the main
>>> topics for Swift 4 that Chris highlighted in
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>>
>>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>>> the schedule...
>>>
>>>
>>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> It was stated that 27th of July was the last date for proposal
>>> acceptance, 29th of July was the last day for implementation, and 1th of
>>> August should be the starting day of Swift 3.1-related discussions.
>>> Am I right? Should we begin?
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Chris Lattner via swift-evolution]

> On Aug 2, 2016, at 2:41 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> Here is the proposal draft:
> https://github.com/Anton3/swift-evolution/blob/remove-precedence-bitwise-arithmetic.md/proposals/-remove-precedence-bitwise-arithmetic.md
>  
> 
> 
> Motivation will be the most difficult section here.

Yes, it will.  Some 2c to consider:

1) Swift 4 is being designed with the ability to all us to make “source 
changes" that don’t break existing source code.

2) It is really important that we continue to polish the language to make it 
great for the long term, so the spirit of your proposal is great to explore.

3) That said, any source breaking change needs to be *very* strongly motivated. 
 To make this change, you should find evidence of common bugs that would be 
solved by this, evidence of actual user confusion in practice, etc.

4) Assuming all of the above works out, we still won’t be able to evaluate the 
proposal until we have the exact details of how the “source stability” model 
works.  Until we have that model, we don’t know that this proposal will be able 
to be covered by it.

On #4, I’m pretty certain that we will be fine, but until we have the model 
nailed down, we procedurally can’t even have the formal review period.  In any 
case, you need to build a specific proposal with very strong rationale first.  
:-)

-Chris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

[Chris Lattner via swift-evolution]

If you see such a drastic slowdown, then tat sounds like a critical regression 
that you found in the latest beta.  We would really appreciate a bug report 
(radar or jira) with a testcase!

-Chris

> On Aug 2, 2016, at 7:38 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> I'd like to echo Muse's point. Accelerate is no solution: it's not available 
> on Linux (and cross-platform numerics is very much essential for the 
> sciences--I assume engineering and finance as well); moreover, it doesn't 
> solve the issue of, as you point out, other kinds of math.
> 
> The appeal to me of Swift was that it promised a memory-safe-by-default 
> systems programming language, a compiled language with performance that can 
> be in the same ballpark as C. So while specialized libraries like BLAS can 
> speed up matrix algebra considerably, IMO, the same kinds of math that are 
> done in C or Go or Rust without calling BLAS should perform roughly 
> equivalently when ported to Swift. That it doesn't should be a bug, and the 
> workaround shouldn't have to be dropping down to or calling out to libraries 
> written in C or Fortran.
> 
> Recently, I discovered that a straightforward numerics algorithm that only 
> adds, divides, multiplies, and compares floating point values slowed down 
> five to ten *times* between preview 3 and preview 4. This was stunning--and 
> if performance ever was comparable to C before (I didn't check for this 
> particular function), I know for sure that it isn't anymore! Although I'm 
> confident that the underlying cause will be found, it does raise questions as 
> to the continued wisdom of writing even somewhat performance-sensitive math 
> in Swift.
>> On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution 
>>  wrote:
>> Well, it depends on what kind of Math you’re trying to do. The Accelerate 
>> framework is available if you need performance.
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Aug 1, 2016, at 18:01, Muse M via swift-evolution 
>>>  wrote:
>>> 
>>> Have always wonder why Maths in Swift is slower than C and Go, it should be 
>>> address with priority if Swift is to be adopt for engineering, financial 
>>> and science industry.
>>> 
>>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
>>>  wrote:
 See 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
 
 From what I understand, the discussion should stay focused on the main 
 topics for Swift 4 that Chris highlighted in 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
 
 I had several ideas in mind, but am postponing them for Swift 5, seeing 
 the schedule...
 
 
> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
>  wrote:
> 
> It was stated that 27th of July was the last date for proposal 
> acceptance, 29th of July was the last day for implementation, and 1th of 
> August should be the starting day of Swift 3.1-related discussions.
> Am I right? Should we begin?
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Improved value and move semantics

[Dave Abrahams via swift-evolution]

on Tue Aug 02 2016, Brent Royal-Gordon  wrote:

>> On Aug 2, 2016, at 12:06 PM, Dave Abrahams via swift-evolution 
>>  wrote:
>> 
>> If it says that, it's... not quite right.  There are things we could do
>> to make some value copies more optimal.  For example, any value type
>> containing multiple class references—or multiple other value types (such
>> as arrays or strings or dictionaries) that contain class references—will
>> cost more to copy than a single class reference does.  At the cost of
>> some allocation and indirection, we could reduce the copying cost of
>> such values.  It's an optimization we've considered making, but haven't
>> prioritized.  
>> 
>> You can put a CoW wrapper around your value to do it manually.  I hacked
>> one up using ManagedBuffer for someone at WWDC but I don't seem to have
>> saved the code, sadly.
>
> Slightly off-topic, but one day I would like to see `indirect` turned
> into a generalized COW feature:
>
> * `indirect` can only be applied to a value type (or at least to a
> type with `mutating` members, so reference types would have to gain
> those).
> * The value type is boxed in a reference type.
> * Any use of a mutating member (and thus, use of the setter) is
> guarded with `isKnownUniquelyReferenced` and a copy.
> * `indirect` can be applied to an enum case with a payload (the
> payload is boxed), a stored property (the value is boxed), or a type
> (the entire type is boxed).
>
> Then you can just slap `indirect` on a struct whose copying is too
> complicated and let Swift transparently COW it for you. (And it would
> also permit recursive structs and other such niceties.)

My vision for this feature is:

a. We indirect automatically based on some heuristic, as an
   optimization.

b. We allow you to indirect manually.

c. We provide an attribute that suppresses automatic indirection to
   whatever depth possible given resilience boundaries.

-- 
-Dave
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] ExpressibleByStringInterpolation vs. String re-evaluation vs. Regex

[Brent Royal-Gordon via swift-evolution]

> On Jul 30, 2016, at 10:35 PM, Jacob Bandes-Storch via swift-evolution 
>  wrote:
> 
> In the past, there has been some interest in refining the behavior of 
> ExpressibleByStringInterpolation (née StringInterpolationConvertible), for 
> example:
> 
> - Ability to restrict the types that can be used as interpolation segments
> - Ability to distinguish the string-literal segments from interpolation 
> segments whose type is String
> 
> Some prior discussions: 
> - "StringInterpolationConvertible and StringLiteralConvertible inheritance" 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017654.html
> - Sub-discussion in "Allow multiple conformances to the same protocol" 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160606/020746.html
> - "StringInterpolationConvertible: can't distinguish between literal 
> components and String arguments"  https://bugs.swift.org/browse/SR-1260 / 
> rdar://problem/19800456&18681780
> - "Proposal: Deprecate optionals in string interpolation" 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018000.html
> 
> 
> About Swift 4, Chris wrote:
>  - String re-evaluation: String is one of the most important fundamental 
> types in the language.  The standard library leads have numerous ideas of how 
> to improve the programming model for it, without jeopardizing the goals of 
> providing a unicode-correct-by-default model.  Our goal is to be better at 
> string processing than Perl!
> 
> I'd be interested in any more detail the team can provide on this. I'd like 
> to talk about string interpolation improvements, but it wouldn't be wise to 
> do so without keeping an eye towards possible regex/pattern-binding syntax, 
> and the String refinements that the stdlib team has in mind, if there's a 
> chance they would affect interpolation.
> 
> Discuss!

I'm not one of the core team, so all I can really provide is a use case.

Given a LocalizedString type like:

/// Conforming types can be included in a LocalizedString.
protocol LocalizedStringConvertible {
/// The format to use for this instance. This format string will be 
included in the key when
/// this type is interpolated into a LocalizedString.
var localizedStringFormat: String { get }

/// The arguments to use when formatting to represent this instance.
var localizedStringArguments: [CVarArg] { get }
}

extension NSString: LocalizedStringConvertible {…}
extension String: LocalizedStringConvertible {…}
extension LocalizedString: LocalizedStringConvertible {…}

extension Int: LocalizedStringConvertible {…}
// etc.

struct LocalizedString {
/// Initializes a LocalizedString by applying the `arguments` to the 
format string with the 
/// indicated `key` using `String.init(format:arguments:)`.
/// 
/// If the `key` does not exist in the localized string file, the `key` 
itself will be used as 
/// the format string.
init(key: String, formattedWith arguments: [CVarArg]) {…}
}

extension String {
init(_ localizedString: LocalizedString) {
self.init(describing: localizedString)
}
}

extension LocalizedString {
/// Initializes a LocalizedString with no arguments which uses the 
indicated `key`. `%` 
/// characters in the `key` will be converted to `%%`.
/// 
/// If the `key` does not exist in the localized string file, the `key` 
itself will be used as 
/// the string.
init(key: String) {…}

/// Initializes a LocalizedString to represent the indicated `value`.
init(_ value: LocalizedStringConvertible) {…}

/// Initializes a LocalizedString to represent the empty string.
init() {…}
}

extension LocalizedString: CustomStringConvertible {…}

extension LocalizedString: ExpressibleByStringLiteral {
init(stringLiteral value: String) {
self.init(key: value)
}
…
}

The current ExpressibleByStringInterpolation protocol has a number of defects.

1. We want to only permit LocalizedStringConvertible types, or at least 
*use* the LocalizedStringConvertible conformance; neither of these appears to 
be possible. (`is` and `as?` casts always fail, overloads don't seem to be 
called, etc.)

2. The literal parts of the string are interpreted using `String`'s 
`ExpressibleByStringLiteral` conformance; we really want them to use 
`LocalizedString`'s instead. 

3. We don't want the literal parts of the string to pass through 
`init(stringInterpolationSegment:)`, because we want to treat interpolation and 
literal segments differnetly.

In other words, we want to be able to write something like this:

extension LocalizedString: ExpressibleByStringInterpolation {
typealias StringInterpolatableType = 

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

I think we can all agree that you should be allowed to use parentheses
whenever it helps you to clarify your meaning. I can also assure you,
however, that when you really get into using these operators for heavy
math, nesting  also hinders clarity.

As always, the question of how much of this choice should be enforced by
the compiler and standard library is a nuanced discussion. C, at one
extreme, has flourished with a much more complicated set of precedence
rules and no enforcement of how parentheses are used. Swift can and already
does do better; now, the question is, are even more restrictions better?
How much more and how much better?

My personal opinion is that we have nearly the right amount of rules, with
maybe one or two more tweaks at most. Reason: any additional requirements
by the compiler and standard library cannot be optionally waived by the
user, but a user can always choose to add more parentheses than required.
Designers of Swift can help readers of code by _encouraging_ writers of
code to improve clarity, but in the end we must design the language for a
reasonably well-meaning writer; it's a fool's errand to try to use the
standard library to defend clarity against the wishes of an unwilling
writer.
On Tue, Aug 2, 2016 at 19:10 Boris Wang  wrote:

> C is my working language，I don' want to remember too much rules for
> operator, just use parentheses.
>
> It's more reliable than the complicated rules.
>
>
> Xiaodi Wu via swift-evolution 于2016年8月3日
> 周三05:55写道：
>
>> Well, there I disagree. All of these operations take integers and produce
>> other integers. As we've discussed, the bitwise operators resemble
>> multiplication or addition in particular ways; not so different at all.
>> This is IMO a weak argument because you're arguing gradations of "so
>> different", which is entirely subjective in the end.
>>
>> What I'm saying is that I would be mildly in favor of your proposal
>> because I can justify it on the basis of something black-and-white:
>> conflicting "levels" at which these operators work on integers (collection
>> of bits vs. element in the set of all integers) and the concomitant
>> differences regarding when these operators trap.
>> On Tue, Aug 2, 2016 at 16:49 Anton Zhilin  wrote:
>>
>>> 2016-08-03 0:46 GMT+03:00 Xiaodi Wu :
>>>
 It's not that << will overflow and / will not. Substitute * for / and
 the argument would be the same. The difference is that << traps when you
 shift more than the total number of bits but does *not* trap when you shift
 numbers off as would arithmetic exponentiation; * traps on overflow. Thus,
 what << is concerned about is the bits (as it should), but * is concerned
 about the max representable value.
>>>
>>>
>>> Substitute * for / and my argument would also be the same :)
>>>
>> ___
>
>
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Boris Wang via swift-evolution]

C is my working language，I don' want to remember too much rules for
operator, just use parentheses.

It's more reliable than the complicated rules.


Xiaodi Wu via swift-evolution 于2016年8月3日
周三05:55写道：

> Well, there I disagree. All of these operations take integers and produce
> other integers. As we've discussed, the bitwise operators resemble
> multiplication or addition in particular ways; not so different at all.
> This is IMO a weak argument because you're arguing gradations of "so
> different", which is entirely subjective in the end.
>
> What I'm saying is that I would be mildly in favor of your proposal
> because I can justify it on the basis of something black-and-white:
> conflicting "levels" at which these operators work on integers (collection
> of bits vs. element in the set of all integers) and the concomitant
> differences regarding when these operators trap.
> On Tue, Aug 2, 2016 at 16:49 Anton Zhilin  wrote:
>
>> 2016-08-03 0:46 GMT+03:00 Xiaodi Wu :
>>
>>> It's not that << will overflow and / will not. Substitute * for / and
>>> the argument would be the same. The difference is that << traps when you
>>> shift more than the total number of bits but does *not* trap when you shift
>>> numbers off as would arithmetic exponentiation; * traps on overflow. Thus,
>>> what << is concerned about is the bits (as it should), but * is concerned
>>> about the max representable value.
>>
>>
>> Substitute * for / and my argument would also be the same :)
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Paulo Faria via swift-evolution]

> On Aug 2, 2016, at 3:17 PM, Tim Vermeulen via swift-evolution 
>  wrote:
> 
> For what it’s worth: Discourse has a Mailing List mode, which will send you 
> an email every time someone makes a new topic or replies to an existing topic 
> (apart from the topics you muted). You can then reply to that email to post a 
> reply in that topic, just like in a mailing list.


Yeah. That’s what I was going to say. Forums can become emails easily.


> On Aug 2, 2016, at 2:30 PM, Kevin Ballard via swift-evolution 
>  wrote:
> 
> I don't understand the suggestions for Slack. That would be a wildly 
> inappropriate medium for long-form discussions that need to be visible to the 
> wider community. Slack is a real-time chat platform, appropriate for 
> immediate discussions between a small set of people. So, for example, you 
> might use Slack when talking with your proposal co-author about polishing up 
> the proposal you're writing together prior to submitting. But you certainly 
> wouldn't use it to actually discuss the proposal idea with the wider 
> community.


Exactly my point about Slack. It would be nice to use it for discussions 
*before* they’re eligible for a proper proposal. Obviously a proposal couldn’t 
be accepted if it was only shared and discussed in Slack. That’s not even 
possible. The idea is to make the forum cleaner, by having only discussions of 
ideas that passed the early stage. For small things use Slack. Don’t clutter 
the forum.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

[Michael Peternell via swift-evolution]

Haha ;)

1) Maybe converting the algorithm into a tail-recursive form should be the 
first optimization?

func factorial(_ n: Int, multipliedBy m: Int = 1) -> Int {
return n <= 1 ? m : factorial(n-1, multipliedBy: m*n)
}

2) Using a non-recursive algorithm would improve performance even more, I guess.

3) The third is maybe to use precalculation or an efficient algorithm that 
doesn't call `factorial` that often. (Assuming that your use-case isn't just 
calculating factorial numbers for fun.) (E.g. if you try to calculate (52 over 
3) by using the formula (52!/(49!*3!)) it will be inefficient, and btw it will 
crash, because 52! does not fit into an Int. The efficient way is 52*51/2*50/3 
("*","/": same precedence, left-associative.)) On my 64-bit computer I cannot 
go beyond 20!, factorial(21) gives an EXC_BAD_INSTRUCTION a.k.a. integer 
overflow. There is no point in optimizing 20!, and there certainly is no point 
in optimizing 40!, at least with Int's.

There is really no point in optimizing that anymore beyond that. A silly 
SIMD-optimized algorithm is always worse than a well-designed algorithm 
compiled with -O0. If you do standard optimization techniques first, the 
advantage of SIMD-instructions for factorial become unmeasurable ;)

However, I agree that special optimizations for numeric computations (SIMD and 
other extension) would be cool..

-Michael

> Am 02.08.2016 um 18:37 schrieb Muse M via swift-evolution 
> :
> 
> I'm concern if simd could improve factorials code and faster timing.
> 
> import simd
> func factorial(n: Int) -> Int {
> return n < 1 ? 1 : n * factorial(n: n - 1)
> }
> print(factorial(n: 40))
> 
> 
> On Wed, Aug 3, 2016 at 12:00 AM, Charlie Monroe  
> wrote:
> That's a good point. :)
> 
>> On Aug 2, 2016, at 5:55 PM, Xiaodi Wu  wrote:
>> 
>> I'm going to guess, since Musa mentioned science and engineering, that a 
>> good chunk of that work is floating point :)
>> 
>> 
>> On Tue, Aug 2, 2016 at 10:41 AM, Charlie Monroe via swift-evolution 
>>  wrote:
>> Are you using the variants of operators without overflow check? I.e.
>> 
>> let num = a &+ b // [1]
>> 
>> [1] 
>> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
>> 
>> 
>> 
>>> On Aug 2, 2016, at 3:01 AM, Muse M  wrote:
>>> 
>>> Have always wonder why Maths in Swift is slower than C and Go, it should be 
>>> address with priority if Swift is to be adopt for engineering, financial 
>>> and science industry.
>>> 
>>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
>>>  wrote:
>>> See 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>> 
>>> From what I understand, the discussion should stay focused on the main 
>>> topics for Swift 4 that Chris highlighted in 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>> 
>>> I had several ideas in mind, but am postponing them for Swift 5, seeing the 
>>> schedule...
>>> 
>>> 
 On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
  wrote:
 
 It was stated that 27th of July was the last date for proposal acceptance, 
 29th of July was the last day for implementation, and 1th of August should 
 be the starting day of Swift 3.1-related discussions.
 Am I right? Should we begin?
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Felipe Cypriano via swift-evolution]

I think this thread should focus on the mailing list vs forum, Slack is
not a forum. It could be nice to have it as an extra if we need it.

It looks to me that all benefits of a mailing list can be achieved by a
forum system with excellent support to read and reply using emails. But
the opposite is not true, one single simple example: we can't even link
related thread using email (as Tino mentioned on the Gmane thread).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

Well, there I disagree. All of these operations take integers and produce
other integers. As we've discussed, the bitwise operators resemble
multiplication or addition in particular ways; not so different at all.
This is IMO a weak argument because you're arguing gradations of "so
different", which is entirely subjective in the end.

What I'm saying is that I would be mildly in favor of your proposal because
I can justify it on the basis of something black-and-white: conflicting
"levels" at which these operators work on integers (collection of bits vs.
element in the set of all integers) and the concomitant differences
regarding when these operators trap.
On Tue, Aug 2, 2016 at 16:49 Anton Zhilin  wrote:

> 2016-08-03 0:46 GMT+03:00 Xiaodi Wu :
>
>> It's not that << will overflow and / will not. Substitute * for / and the
>> argument would be the same. The difference is that << traps when you shift
>> more than the total number of bits but does *not* trap when you shift
>> numbers off as would arithmetic exponentiation; * traps on overflow. Thus,
>> what << is concerned about is the bits (as it should), but * is concerned
>> about the max representable value.
>
>
> Substitute * for / and my argument would also be the same :)
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Paulo Faria via swift-evolution]

+1 for Forum and Slack. Slack is good for informal discussion and early ideas. 
This could make the forum more focused because only ideas that passed the early 
phase of discussion would end up on the forum. If one doesn’t have time to hang 
out on the chat that’s not a problem. The forum would be the place for those. 
Forum is much better than email. Discourse seems pretty nice.

> On Aug 2, 2016, at 12:04 PM, Brad Hilton via swift-evolution 
>  wrote:
> 
> +1. I would love to see Swift Evolution on Slack or a forum, it would be so 
> much easier to manage.
> 
> Brad
> 
>> Branching...
>> 
>> On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via 
>> swift-evolutionwrote:
>>> On Jul 29, 2016, at 5:14 PM, Brandon 
>>> Knopewrote:
 
 Chris, has the core team discussed opening up a forum for discussing 
 proposal implementations.
 
 Some of us aren't as skilled as the core team or other contributors but 
 would like to learn. A forum is a much easier place for us to post for 
 code help and to help others with their questions. I think this could help 
 get more involved as it would be a more comfortable format for them. Think 
 of how there are Apple Developer forums and not mailing lists for iOS 
 betas etc.
 
 I am not saying moving swift-evo to forums *yet* but I believe a lot of 
 the newer programmers are more comfortable with a forum format, especially 
 when it comes to help and discussing code.
 
 Forums for contributors would:
 - be more familiar for a lot of the newer and not as experienced developers
 - be easier to search
 - be easier to moderate (not really a problem yet)
>>> 
>>> Hi Brandon,
>>> 
>>> Moving from email to a forum system has come up before, but they have some 
>>> disadvantages.One of major wins of email is that it is pervasive and can be 
>>> adapted into other forms.For example, if you haven’t seen it yet, check out:
>>> https://stylemac.com/hirundo/
>>> 
>>> -Chris
>>> 
>> We've discussed forums on swift-evolution before. Maybe it's time for 
>> another go, with Swift 3 winding down.
>> 
>> For context, prior discussions are on this 
>> thread:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
>> 
>> (-1 for mailman: it's hard for me to even properly find to all the 
>> prior discussion about mailing lists, because of how mailman's archive 
>> works...)
>> 
>> 
>> News in the last few days is that Gmane is at least temporarily 
>> disappearing:https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
>> 
>> 
>> I'd just like to vote once again 
>> forDiscourse(http://www.discourse.org/faq/#what):-Excellent web 
>> interface(https://meta.discourse.org/), from the people who brought you 
>> Stack Overflow(built-in search, etc.)
>> - Read via email if that's your thing: it has "mailing list mode" which 
>> includes 1-email-per-post, if that's your cup of tea
>> -Reply via 
>> email(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)if 
>> that's your thing
>> - It'sopen source(https://github.com/discourse/discourse)itself
>> - I believe it has ways of getting content as JSON and/or RSS, so I'd hardly 
>> say "can be adapted into other forms" is an exclusive feature of email.
>> 
>> And, Discourse providesfree hosting for community-friendly open-source 
>> projects(http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/).
>>  Istrongly 
>> suspect(https://twitter.com/jtbandes/status/705886542309363712)Swift would 
>> qualify for this.
>> 
>> 
>> There have been several people on this list arguing in favor of mailing 
>> lists — I encourage folks to go read the old thread for themselves.
>> 
>> It's worth noting there are also plenty of voices that don't get heard on 
>> this list, because people just don't like using mailing lists. One 
>> example:https://twitter.com/pilky/status/755105431555608580___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Anton Zhilin via swift-evolution]

2016-08-03 0:46 GMT+03:00 Xiaodi Wu :

> It's not that << will overflow and / will not. Substitute * for / and the
> argument would be the same. The difference is that << traps when you shift
> more than the total number of bits but does *not* trap when you shift
> numbers off as would arithmetic exponentiation; * traps on overflow. Thus,
> what << is concerned about is the bits (as it should), but * is concerned
> about the max representable value.


Substitute * for / and my argument would also be the same :)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

It's not that << will overflow and / will not. Substitute * for / and the
argument would be the same. The difference is that << traps when you shift
more than the total number of bits but does *not* trap when you shift
numbers off as would arithmetic exponentiation; * traps on overflow. Thus,
what << is concerned about is the bits (as it should), but * is concerned
about the max representable value.
On Tue, Aug 2, 2016 at 16:41 Anton Zhilin  wrote:

> Here is the proposal draft:
>
> https://github.com/Anton3/swift-evolution/blob/remove-precedence-bitwise-arithmetic.md/proposals/-remove-precedence-bitwise-arithmetic.md
>
> Motivation will be the most difficult section here.
>
> 2016-08-02 23:30 GMT+03:00 Xiaodi Wu :
>
>> Let me give you theoretical basis for why I'm +0.5 on branching off
>> binary operators but not these other ones. Félix is absolutely right that
>> `a << b / c` mixes two things. It's not merely that they're in two
>> "different" domains. It's that these two operators take the same values of
>> the same type and operate on them in fundamentally disparate ways.
>>
>> This is a bad way of phrasing it, I know--let me try to clarify: the
>> operator `<<` operates on an integer as a fixed-length collection of bits;
>> the operator `/` operates on an integer as a number, an element in the set
>> of all integers. The practical consequence is that overflow behavior can be
>> subtly different; the overflow behavior of << is 'obvious' if you're
>> thinking about an integer as a fixed-length collection of bits but
>> surprising if you think of it as an integer being multiplied by an exponent
>> of two. Thus, it is best to separate operators that work on integers as a
>> collection of bits from the other numeric operators.
>>
>> In no other of your proposed branches do I find the same fundamental
>> conflict.
>>
>
> And that argumentation seems insufficient to me. Assuming that everyone
> knows precedence table, 'a << b / c` should not be ambiguous. I'd argue
> that it's easy to understand that << operation will overflow here and /
> will not.
> Instead, I suggest that these operations are so different that any
> precedence relationship between them is meaningless (another wording of
> explanation with domains).
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Anton Zhilin via swift-evolution]

Here is the proposal draft:
https://github.com/Anton3/swift-evolution/blob/remove-precedence-bitwise-arithmetic.md/proposals/-remove-precedence-bitwise-arithmetic.md

Motivation will be the most difficult section here.

2016-08-02 23:30 GMT+03:00 Xiaodi Wu :

> Let me give you theoretical basis for why I'm +0.5 on branching off binary
> operators but not these other ones. Félix is absolutely right that `a << b
> / c` mixes two things. It's not merely that they're in two "different"
> domains. It's that these two operators take the same values of the same
> type and operate on them in fundamentally disparate ways.
>
> This is a bad way of phrasing it, I know--let me try to clarify: the
> operator `<<` operates on an integer as a fixed-length collection of bits;
> the operator `/` operates on an integer as a number, an element in the set
> of all integers. The practical consequence is that overflow behavior can be
> subtly different; the overflow behavior of << is 'obvious' if you're
> thinking about an integer as a fixed-length collection of bits but
> surprising if you think of it as an integer being multiplied by an exponent
> of two. Thus, it is best to separate operators that work on integers as a
> collection of bits from the other numeric operators.
>
> In no other of your proposed branches do I find the same fundamental
> conflict.
>

And that argumentation seems insufficient to me. Assuming that everyone
knows precedence table, 'a << b / c` should not be ambiguous. I'd argue
that it's easy to understand that << operation will overflow here and /
will not.
Instead, I suggest that these operations are so different that any
precedence relationship between them is meaningless (another wording of
explanation with domains).
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Douglas Gregor via swift-evolution]

> On Aug 2, 2016, at 2:19 PM, Jon Shier  wrote:
> 
>   Thanks Doug. I missed the rename, as earlier points still referred to 
> ErrorProtocol. In regards to the CloudKit errors, I appreciate the strongly 
> typed CKError, but why not have the methods return that type directly?

Generally speaking, Cocoa only uses NSError—not specific subclasses or NSError 
or other error types—because errors can occur at many different places in the 
stack and be propagated up. A CloudKit operation could fail because of some 
problem detected in a different error domain—say, the general Cocoa error 
domain or URLError domain—and that non-CloudKit error would get passed through 
immediately. So, if you were assuming that every error you get here had to be 
in the CloudKit error domain, I believe your code was already incorrect. It is 
*possible* that CloudKit translates/wraps all other errors, but that would be 
odd for a Cocoa framework.

> Every usage of these methods is going to require such a cast, so why require 
> it in the first place? I don’t understand what advantage erasing the strongly 
> type error that was just created has when the developer will just have to 
> bring it right back. Or is this just a first implementation?

There was never a strongly-typed error, and in most Cocoa cases there shouldn’t 
be one because NSError covers all error domains, by design.

- Doug


> 
> 
> Jon
> 
>> On Aug 2, 2016, at 4:20 PM, Douglas Gregor > > wrote:
>> 
>>> 
>>> On Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution 
>>> > wrote:
>>> 
>>> I’m not sure where to put such feedback, but the ErrorProtocol to Error 
>>> rename that accompanied the implementation of this proposal is very, very 
>>> painful. It completely eliminates the very useful ability to embed an 
>>> associated Error type inside other types, as those types now conflict with 
>>> the protocol. Also, was this rename accompanied by an evolution proposal? 
>>> It seems like the change was just made when this proposal was implemented.
>> 
>> The rename was part of the proposal, in bullet #5 of the proposed solution 
>> (which, amusing, pastes as bullet #1 below):
>> 
>> Rename ErrorProtocol to Error: once we've completed the bridging story, 
>> Error becomes the primary way to work with error types in Swift, and the 
>> value type to which NSError is bridged:
>> 
>> func handleError(_ error: Error, userInteractionPermitted: Bool)
>> 
>> 
>>> Also, the adoption of this proposal by the Cocoa(Touch) frameworks as 
>>> seen in Xcode 8 beta 4 has made asynchronous error handling quite a bit 
>>> more arduous. For example, the CKDatabase method fetch(withRecordID 
>>> recordID: CKRecordID, completionHandler: (CKRecord?, Error?) -> Void) 
>>> returns an `Error` now, meaning I have to cast to the specific `CKError` 
>>> type to get useful information out of it. Is this just an unfortunate first 
>>> effort that will be fixed, or is this the expected form of these sorts of 
>>> APIs after this proposal?
>> 
>> Prior to this proposal, you would have had to check the domain against 
>> CKErrorDomain anyway to determine whether you’re looking at a CloudKit error 
>> (vs. some other error that is passing through CloudKit), so error bridging 
>> shouldn’t actually be adding any work here—although it might be making 
>> explicit work that was already done or should have been done. Once you have 
>> casted to CKError, you now have typed accessors for information in the error:
>> 
>> extension CKError {
>>   /// Retrieve partial error results associated by item ID.
>>   public var partialErrorsByItemID: [NSObject : Error]? {
>> return userInfo[CKPartialErrorsByItemIDKey] as? [NSObject : Error]
>>   }
>> 
>>   /// The original CKRecord object that you used as the basis for
>>   /// making your changes.
>>   public var ancestorRecord: CKRecord? {
>> return userInfo[CKRecordChangedErrorAncestorRecordKey] as? CKRecord
>>   }
>> 
>>   /// The CKRecord object that was found on the server. Use this
>>   /// record as the basis for merging your changes.
>>   public var serverRecord: CKRecord? {
>> return userInfo[CKRecordChangedErrorServerRecordKey] as? CKRecord
>>   }
>> 
>>   /// The CKRecord object that you tried to save. This record is based
>>   /// on the record in the CKRecordChangedErrorAncestorRecordKey key
>>   /// but contains the additional changes you made.
>>   public var clientRecord: CKRecord? {
>> return userInfo[CKRecordChangedErrorClientRecordKey] as? CKRecord
>>   }
>> 
>>   /// The number of seconds after which you may retry a request. This
>>   /// key may be included in an error of type
>>   /// `CKErrorServiceUnavailable` or `CKErrorRequestRateLimited`.
>>   public var retryAfterSeconds: Double? {
>> return userInfo[CKErrorRetryAfterKey] as? Double
>>   }
>> }
>>  - Doug
>> 
>>> 
>>> 

Re: [swift-evolution] Improved value and move semantics

[Brent Royal-Gordon via swift-evolution]

> On Aug 2, 2016, at 12:06 PM, Dave Abrahams via swift-evolution 
>  wrote:
> 
> If it says that, it's... not quite right.  There are things we could do
> to make some value copies more optimal.  For example, any value type
> containing multiple class references—or multiple other value types (such
> as arrays or strings or dictionaries) that contain class references—will
> cost more to copy than a single class reference does.  At the cost of
> some allocation and indirection, we could reduce the copying cost of
> such values.  It's an optimization we've considered making, but haven't
> prioritized.  
> 
> You can put a CoW wrapper around your value to do it manually.  I hacked
> one up using ManagedBuffer for someone at WWDC but I don't seem to have
> saved the code, sadly.

Slightly off-topic, but one day I would like to see `indirect` turned into a 
generalized COW feature:

* `indirect` can only be applied to a value type (or at least to a type with 
`mutating` members, so reference types would have to gain those).
* The value type is boxed in a reference type.
* Any use of a mutating member (and thus, use of the setter) is guarded with 
`isKnownUniquelyReferenced` and a copy.
* `indirect` can be applied to an enum case with a payload (the payload is 
boxed), a stored property (the value is boxed), or a type (the entire type is 
boxed).

Then you can just slap `indirect` on a struct whose copying is too complicated 
and let Swift transparently COW it for you. (And it would also permit recursive 
structs and other such niceties.)

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Kevin Ballard via swift-evolution]

You're assuming that every error passed to that method is a CKError. The
documentation does not claim that to be true, so it's quite plausible
that you might get other errors that are simply passed through.

-Kevin

On Tue, Aug 2, 2016, at 02:19 PM, Jon Shier via swift-evolution wrote:
> Thanks Doug. I missed the rename, as earlier points still referred to
> ErrorProtocol. In regards to the CloudKit errors, I appreciate the
> strongly typed CKError, but why not have the methods return that type
> directly? Every usage of these methods is going to require such a
> cast, so why require it in the first place? I don’t understand what
> advantage erasing the strongly type error that was just created has
> when the developer will just have to bring it right back. Or is this
> just a first implementation?
>
>
> Jon
>
>> On Aug 2, 2016, at 4:20 PM, Douglas Gregor  wrote:
>>
>>>
>>> On Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution >> evolut...@swift.org> wrote:
>>>
>>> I’m not sure where to put such feedback, but the ErrorProtocol to
>>> Error rename that accompanied the implementation of this proposal is
>>> very, very painful. It completely eliminates the very useful ability
>>> to embed an associated Error type inside other types, as those types
>>> now conflict with the protocol. Also, was this rename accompanied by
>>> an evolution proposal? It seems like the change was just made when
>>> this proposal was implemented.
>>
>> The rename was part of the proposal, in bullet #5 of the proposed
>> solution (which, amusing, pastes as bullet #1 below):
>>
>>  1. Rename ErrorProtocol to Error: once we've completed the bridging
>> story, Error becomes the primary way to work with error types in
>> Swift, and the value type to which NSError is bridged:


>> func handleError(_ error: Error, userInteractionPermitted: Bool)
>>
>>
>>> Also, the adoption of this proposal by the Cocoa(Touch) frameworks
>>> as seen in Xcode 8 beta 4 has made asynchronous error handling quite
>>> a bit more arduous. For example, the CKDatabase method
>>> fetch(withRecordID recordID: CKRecordID, completionHandler:
>>> (CKRecord?, Error?) -> Void) returns an `Error` now, meaning I have
>>> to cast to the specific `CKError` type to get useful information out
>>> of it. Is this just an unfortunate first effort that will be fixed,
>>> or is this the expected form of these sorts of APIs after this
>>> proposal?
>>
>> Prior to this proposal, you would have had to check the domain
>> against CKErrorDomain anyway to determine whether you’re looking at a
>> CloudKit error (vs. some other error that is passing through
>> CloudKit), so error bridging shouldn’t actually be adding any work
>> here—although it might be making explicit work that was already done
>> or should have been done. Once you have casted to CKError, you now
>> have typed accessors for information in the error:
>>
>> extension CKError {
>>   /// Retrieve partial error results associated by item ID.
>>   public var partialErrorsByItemID: [NSObject : Error]? {
>> return userInfo[CKPartialErrorsByItemIDKey] as? [NSObject :
>> Error]
>>   }
>>
>>   /// The original CKRecord object that you used as the basis for
>>   /// making your changes.
>>   public var ancestorRecord: CKRecord? {
>> return userInfo[CKRecordChangedErrorAncestorRecordKey] as?
>> CKRecord
>>   }
>>
>>   /// The CKRecord object that was found on the server. Use this
>>   /// record as the basis for merging your changes.
>>   public var serverRecord: CKRecord? {
>> return userInfo[CKRecordChangedErrorServerRecordKey] as? CKRecord
>>   }
>>
>>   /// The CKRecord object that you tried to save. This record is
>>   based
>>   /// on the record in the CKRecordChangedErrorAncestorRecordKey key
>>   /// but contains the additional changes you made.
>>   public var clientRecord: CKRecord? {
>> return userInfo[CKRecordChangedErrorClientRecordKey] as? CKRecord
>>   }
>>
>>   /// The number of seconds after which you may retry a request. This
>>   /// key may be included in an error of type
>>   /// `CKErrorServiceUnavailable` or `CKErrorRequestRateLimited`.
>>   public var retryAfterSeconds: Double? {
>> return userInfo[CKErrorRetryAfterKey] as? Double
>>   }
>> }
>> - Doug
>>
>>>
>>>
>>>
>>> Jon Shier
>>>
>>>
 On Jul 12, 2016, at 8:44 AM, Shawn Erickson via swift-evolution >>> evolut...@swift.org> wrote:

 Thanks for the effort on the proposal and discussion and thanks to
 those working in the implementation.

 -Shawn
 On Tue, Jul 12, 2016 at 12:25 AM Charles Srstka via swift-evolution
  wrote:
> Wow, thanks! I’m delighted that Apple found this improvement to be
> worth inclusion in Swift 3. This will truly make the language much
> nicer to use with the Cocoa frameworks.
>
> Thanks!
>
> Charles
>
> > On Jul 11, 2016, at 11:19 PM, Chris Lattner via swift-evolution
> > 

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Jon Shier via swift-evolution]

Thanks Doug. I missed the rename, as earlier points still referred to 
ErrorProtocol. In regards to the CloudKit errors, I appreciate the strongly 
typed CKError, but why not have the methods return that type directly? Every 
usage of these methods is going to require such a cast, so why require it in 
the first place? I don’t understand what advantage erasing the strongly type 
error that was just created has when the developer will just have to bring it 
right back. Or is this just a first implementation?


Jon

> On Aug 2, 2016, at 4:20 PM, Douglas Gregor  wrote:
> 
>> 
>> On Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution 
>> > wrote:
>> 
>>  I’m not sure where to put such feedback, but the ErrorProtocol to Error 
>> rename that accompanied the implementation of this proposal is very, very 
>> painful. It completely eliminates the very useful ability to embed an 
>> associated Error type inside other types, as those types now conflict with 
>> the protocol. Also, was this rename accompanied by an evolution proposal? It 
>> seems like the change was just made when this proposal was implemented.
> 
> The rename was part of the proposal, in bullet #5 of the proposed solution 
> (which, amusing, pastes as bullet #1 below):
> 
> Rename ErrorProtocol to Error: once we've completed the bridging story, Error 
> becomes the primary way to work with error types in Swift, and the value type 
> to which NSError is bridged:
> 
> func handleError(_ error: Error, userInteractionPermitted: Bool)
> 
> 
>>  Also, the adoption of this proposal by the Cocoa(Touch) frameworks as 
>> seen in Xcode 8 beta 4 has made asynchronous error handling quite a bit more 
>> arduous. For example, the CKDatabase method fetch(withRecordID recordID: 
>> CKRecordID, completionHandler: (CKRecord?, Error?) -> Void) returns an 
>> `Error` now, meaning I have to cast to the specific `CKError` type to get 
>> useful information out of it. Is this just an unfortunate first effort that 
>> will be fixed, or is this the expected form of these sorts of APIs after 
>> this proposal?
> 
> Prior to this proposal, you would have had to check the domain against 
> CKErrorDomain anyway to determine whether you’re looking at a CloudKit error 
> (vs. some other error that is passing through CloudKit), so error bridging 
> shouldn’t actually be adding any work here—although it might be making 
> explicit work that was already done or should have been done. Once you have 
> casted to CKError, you now have typed accessors for information in the error:
> 
> extension CKError {
>   /// Retrieve partial error results associated by item ID.
>   public var partialErrorsByItemID: [NSObject : Error]? {
> return userInfo[CKPartialErrorsByItemIDKey] as? [NSObject : Error]
>   }
> 
>   /// The original CKRecord object that you used as the basis for
>   /// making your changes.
>   public var ancestorRecord: CKRecord? {
> return userInfo[CKRecordChangedErrorAncestorRecordKey] as? CKRecord
>   }
> 
>   /// The CKRecord object that was found on the server. Use this
>   /// record as the basis for merging your changes.
>   public var serverRecord: CKRecord? {
> return userInfo[CKRecordChangedErrorServerRecordKey] as? CKRecord
>   }
> 
>   /// The CKRecord object that you tried to save. This record is based
>   /// on the record in the CKRecordChangedErrorAncestorRecordKey key
>   /// but contains the additional changes you made.
>   public var clientRecord: CKRecord? {
> return userInfo[CKRecordChangedErrorClientRecordKey] as? CKRecord
>   }
> 
>   /// The number of seconds after which you may retry a request. This
>   /// key may be included in an error of type
>   /// `CKErrorServiceUnavailable` or `CKErrorRequestRateLimited`.
>   public var retryAfterSeconds: Double? {
> return userInfo[CKErrorRetryAfterKey] as? Double
>   }
> }
>   - Doug
> 
>> 
>> 
>> 
>> Jon Shier
>>  
>> 
>>> On Jul 12, 2016, at 8:44 AM, Shawn Erickson via swift-evolution 
>>> > wrote:
>>> 
>>> Thanks for the effort on the proposal and discussion and thanks to those 
>>> working in the implementation.
>>> 
>>> -Shawn
>>> On Tue, Jul 12, 2016 at 12:25 AM Charles Srstka via swift-evolution 
>>> > wrote:
>>> Wow, thanks! I’m delighted that Apple found this improvement to be worth 
>>> inclusion in Swift 3. This will truly make the language much nicer to use 
>>> with the Cocoa frameworks.
>>> 
>>> Thanks!
>>> 
>>> Charles
>>> 
>>> > On Jul 11, 2016, at 11:19 PM, Chris Lattner via swift-evolution 
>>> > > wrote:
>>> >
>>> > Proposal Link: 
>>> > https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md
>>> >  
>>> > 

[swift-evolution] Swift Generics: connection between equality constraints on generic parameters and GADTs

[Gabriel Scherer via swift-evolution]

I'm not familiar with Swift, but happened to find the Generics
Manifesto document at
  https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md

I wonder if the Swift community is aware of the strong connection
between equalities on generic type parameters of the form "where T ==
Foo" in method or extension declarations, and the Generalized
Algebraic Datatypes (GADTs) of the functional programming community.
To my knowledge, this relation has first been established in the 2006
article "Generalized Algebraic Data Types and Object-Oriented
Programming", by Andrew Kennedy and Claudio Russo, that contain
examples that you might find interesting:
  
https://www.microsoft.com/en-us/research/publication/generalized-algebraic-data-types-and-object-oriented-programming/

There has been a lot of work on GADTs and their expressiveness in the
functional programming community, and I think that realizing the
connection could be helpful for some further generics language design.

The connection is rather subtle because, while sets of definitions by
cases on algebraic datatypes are known to correspond exactly to sets
of class extensions on a fixed method signature (this is the general
FP/OO duality), the duality do not extend to GADTs and equality
constraints as one could expect. There are simple functional
programming examples that require type parameter constraints to be
expressed in an object-oriented style, and correspondingly some GADTs
that don't need method-level parameter constraints in object-oriented
style. The latter has resulted in some wrong claims in the past that
GADTs are un-necessary in object-oriented languages. See the article
for more details.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

Let me give you theoretical basis for why I'm +0.5 on branching off binary
operators but not these other ones. Félix is absolutely right that `a << b
/ c` mixes two things. It's not merely that they're in two "different"
domains. It's that these two operators take the same values of the same
type and operate on them in fundamentally disparate ways.

This is a bad way of phrasing it, I know--let me try to clarify: the
operator `<<` operates on an integer as a fixed-length collection of bits;
the operator `/` operates on an integer as a number, an element in the set
of all integers. The practical consequence is that overflow behavior can be
subtly different; the overflow behavior of << is 'obvious' if you're
thinking about an integer as a fixed-length collection of bits but
surprising if you think of it as an integer being multiplied by an exponent
of two. Thus, it is best to separate operators that work on integers as a
collection of bits from the other numeric operators.

In no other of your proposed branches do I find the same fundamental
conflict.

On Tue, Aug 2, 2016 at 3:14 PM, Anton Zhilin  wrote:

> 2016-08-02 23:06 GMT+03:00 Xiaodi Wu :
>
>> I'm not sure how you're coming up with "domain areas". Ranges have
>> numbers as bounds; those are typically computed by arithmetic.
>>
>> Virtually the entire stdlib exists to support language features; all
>> other facilities found in other languages' "standard library" are in
>> Foundation.
>>
>> As I mentioned, theoretical justifications have no sway with me. Show me
>> how a real user error is averted by such a change. I see none here; thus, I
>> disagree with the change.
>
>
> Okay, I'm creating a proposal for branching off binary operators, and
> after that I'll try to do a separate proposal for my crazy ideas :)
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Anton Zhilin via swift-evolution]

2016-08-02 21:35 GMT+03:00 David Owens II via swift-evolution <
swift-evolution@swift.org>:

> And you go back to a single point of failure, requirement to host and
> maintain a server, or to pay them to host it for you.
>

Do you suggest to make swift-evolution completely decentralized?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Douglas Gregor via swift-evolution]

> On Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution 
>  wrote:
> 
>   I’m not sure where to put such feedback, but the ErrorProtocol to Error 
> rename that accompanied the implementation of this proposal is very, very 
> painful. It completely eliminates the very useful ability to embed an 
> associated Error type inside other types, as those types now conflict with 
> the protocol. Also, was this rename accompanied by an evolution proposal? It 
> seems like the change was just made when this proposal was implemented.

The rename was part of the proposal, in bullet #5 of the proposed solution 
(which, amusing, pastes as bullet #1 below):

Rename ErrorProtocol to Error: once we've completed the bridging story, Error 
becomes the primary way to work with error types in Swift, and the value type 
to which NSError is bridged:

func handleError(_ error: Error, userInteractionPermitted: Bool)


>   Also, the adoption of this proposal by the Cocoa(Touch) frameworks as 
> seen in Xcode 8 beta 4 has made asynchronous error handling quite a bit more 
> arduous. For example, the CKDatabase method fetch(withRecordID recordID: 
> CKRecordID, completionHandler: (CKRecord?, Error?) -> Void) returns an 
> `Error` now, meaning I have to cast to the specific `CKError` type to get 
> useful information out of it. Is this just an unfortunate first effort that 
> will be fixed, or is this the expected form of these sorts of APIs after this 
> proposal?

Prior to this proposal, you would have had to check the domain against 
CKErrorDomain anyway to determine whether you’re looking at a CloudKit error 
(vs. some other error that is passing through CloudKit), so error bridging 
shouldn’t actually be adding any work here—although it might be making explicit 
work that was already done or should have been done. Once you have casted to 
CKError, you now have typed accessors for information in the error:

extension CKError {
  /// Retrieve partial error results associated by item ID.
  public var partialErrorsByItemID: [NSObject : Error]? {
return userInfo[CKPartialErrorsByItemIDKey] as? [NSObject : Error]
  }

  /// The original CKRecord object that you used as the basis for
  /// making your changes.
  public var ancestorRecord: CKRecord? {
return userInfo[CKRecordChangedErrorAncestorRecordKey] as? CKRecord
  }

  /// The CKRecord object that was found on the server. Use this
  /// record as the basis for merging your changes.
  public var serverRecord: CKRecord? {
return userInfo[CKRecordChangedErrorServerRecordKey] as? CKRecord
  }

  /// The CKRecord object that you tried to save. This record is based
  /// on the record in the CKRecordChangedErrorAncestorRecordKey key
  /// but contains the additional changes you made.
  public var clientRecord: CKRecord? {
return userInfo[CKRecordChangedErrorClientRecordKey] as? CKRecord
  }

  /// The number of seconds after which you may retry a request. This
  /// key may be included in an error of type
  /// `CKErrorServiceUnavailable` or `CKErrorRequestRateLimited`.
  public var retryAfterSeconds: Double? {
return userInfo[CKErrorRetryAfterKey] as? Double
  }
}
- Doug

> 
> 
> 
> Jon Shier
>   
> 
>> On Jul 12, 2016, at 8:44 AM, Shawn Erickson via swift-evolution 
>> > wrote:
>> 
>> Thanks for the effort on the proposal and discussion and thanks to those 
>> working in the implementation.
>> 
>> -Shawn
>> On Tue, Jul 12, 2016 at 12:25 AM Charles Srstka via swift-evolution 
>> > wrote:
>> Wow, thanks! I’m delighted that Apple found this improvement to be worth 
>> inclusion in Swift 3. This will truly make the language much nicer to use 
>> with the Cocoa frameworks.
>> 
>> Thanks!
>> 
>> Charles
>> 
>> > On Jul 11, 2016, at 11:19 PM, Chris Lattner via swift-evolution 
>> > > wrote:
>> >
>> > Proposal Link: 
>> > https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md
>> >  
>> > 
>> >
>> > The review of "SE-0112: Improved NSError Bridging" ran from June 30 ... 
>> > July 4, 2016. The proposal has been *accepted*:
>> >
>> > The community and core team agree that this proposal is a huge step 
>> > forward that enriches the experience working with and extending the Cocoa 
>> > NSError model in Swift.  The core team requests one minor renaming of 
>> > "attemptRecovery(optionIndex:andThen:)" to 
>> > "attemptRecovery(optionIndex:resultHandler:)”.  It also discussed renaming 
>> > CustomNSError and RecoverableError, but decided to stay with those names.
>> >
>> > Thank you to Doug Gregor and Charles Srstka for driving this discussion 
>> > forward, and for Doug Gregor taking the charge on the implementation 
>> > 

Re: [swift-evolution] [Discussion] Breaking precedence

[Anton Zhilin via swift-evolution]

2016-08-02 23:06 GMT+03:00 Xiaodi Wu :

> I'm not sure how you're coming up with "domain areas". Ranges have numbers
> as bounds; those are typically computed by arithmetic.
>
> Virtually the entire stdlib exists to support language features; all other
> facilities found in other languages' "standard library" are in Foundation.
>
> As I mentioned, theoretical justifications have no sway with me. Show me
> how a real user error is averted by such a change. I see none here; thus, I
> disagree with the change.


Okay, I'm creating a proposal for branching off binary operators, and after
that I'll try to do a separate proposal for my crazy ideas :)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

I'm not sure how you're coming up with "domain areas". Ranges have numbers
as bounds; those are typically computed by arithmetic.

Virtually the entire stdlib exists to support language features; all other
facilities found in other languages' "standard library" are in Foundation.

As I mentioned, theoretical justifications have no sway with me. Show me
how a real user error is averted by such a change. I see none here; thus, I
disagree with the change.
On Tue, Aug 2, 2016 at 14:45 Anton Zhilin  wrote:

> If operator <+> is used in one domain area, and operator <-> is used in
> another domain area, then we should not make everyone keep in mind both
> domain areas simultaneously.
>
> Another explanation: operator ... does not belong to "core", "control"
> operators, it belongs to Ranges part of standard library. Likewise, +
> operates on numbers. Therefore they should not have precedence relationship.
>
> Yet another explanation: I believe that optionals and booleans are a lot
> more fundamental in Swift than ranges. Ranges don't have any support in
> language itself, they belong to standard library.
>
> 2016-08-02 22:19 GMT+03:00 Xiaodi Wu :
>
>> What's the benefit? Is there anyone confused by a...b+c?
>>
>> On Tue, Aug 2, 2016 at 14:13 Anton Zhilin  wrote:
>>
>>> 2016-08-02 21:56 GMT+03:00 Xiaodi Wu :
>>>
 I can sort of see what this is getting at, but I simply have no way of
 evaluating whether it's sensible or not without actual examples in code.
 This is, again, a more expansive change than discussed. I'd be interested
 in seeing your write-up on separating arithmetic and bitwise/bitshift
 operators :)

>>> On Tue, Aug 2, 2016 at 1:36 PM, Anton Zhilin 
 wrote:

>>> Here's another possible plan:
> https://gist.github.com/Anton3/e00026409a6f948ca3ba41acf24e9672
>
> There is a base line of "core", control-like operators, which everyone
> must know. "Applied" operators are branched off them. For example, 
> Ternary,
> Comparison or Casting can be selected as base for a new mini-tree of
> related operators.
>
> Following this scheme, there are at least 3 "applied" domains with
> operators: arithmetic, bitwise and range formation. You can see result in
> the gist.
>

>>> Well, I don't suggest changing precedence relationships there (just
>>> removing some), so that should be on-topic, I guess?
>>>
>>> The main change I suggest over separating bitwise operators is
>>> separating RangeFormation, because it's a separate, "applied" operator
>>> domain. It is not control-structure-like, so it does not deserve to be in
>>> the main tree.
>>>
>>> Simplifying even more, I want to prohibit this:  a...b+c
>>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Anton Zhilin via swift-evolution]

If operator <+> is used in one domain area, and operator <-> is used in
another domain area, then we should not make everyone keep in mind both
domain areas simultaneously.

Another explanation: operator ... does not belong to "core", "control"
operators, it belongs to Ranges part of standard library. Likewise, +
operates on numbers. Therefore they should not have precedence relationship.

Yet another explanation: I believe that optionals and booleans are a lot
more fundamental in Swift than ranges. Ranges don't have any support in
language itself, they belong to standard library.

2016-08-02 22:19 GMT+03:00 Xiaodi Wu :

> What's the benefit? Is there anyone confused by a...b+c?
>
> On Tue, Aug 2, 2016 at 14:13 Anton Zhilin  wrote:
>
>> 2016-08-02 21:56 GMT+03:00 Xiaodi Wu :
>>
>>> I can sort of see what this is getting at, but I simply have no way of
>>> evaluating whether it's sensible or not without actual examples in code.
>>> This is, again, a more expansive change than discussed. I'd be interested
>>> in seeing your write-up on separating arithmetic and bitwise/bitshift
>>> operators :)
>>>
>> On Tue, Aug 2, 2016 at 1:36 PM, Anton Zhilin 
>>> wrote:
>>>
>> Here's another possible plan:
 https://gist.github.com/Anton3/e00026409a6f948ca3ba41acf24e9672

 There is a base line of "core", control-like operators, which everyone
 must know. "Applied" operators are branched off them. For example, Ternary,
 Comparison or Casting can be selected as base for a new mini-tree of
 related operators.

 Following this scheme, there are at least 3 "applied" domains with
 operators: arithmetic, bitwise and range formation. You can see result in
 the gist.

>>>
>> Well, I don't suggest changing precedence relationships there (just
>> removing some), so that should be on-topic, I guess?
>>
>> The main change I suggest over separating bitwise operators is separating
>> RangeFormation, because it's a separate, "applied" operator domain. It is
>> not control-structure-like, so it does not deserve to be in the main tree.
>>
>> Simplifying even more, I want to prohibit this:  a...b+c
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

What's the benefit? Is there anyone confused by a...b+c?
On Tue, Aug 2, 2016 at 14:13 Anton Zhilin  wrote:

> 2016-08-02 21:56 GMT+03:00 Xiaodi Wu :
>
>> I can sort of see what this is getting at, but I simply have no way of
>> evaluating whether it's sensible or not without actual examples in code.
>> This is, again, a more expansive change than discussed. I'd be interested
>> in seeing your write-up on separating arithmetic and bitwise/bitshift
>> operators :)
>>
> On Tue, Aug 2, 2016 at 1:36 PM, Anton Zhilin 
>> wrote:
>>
> Here's another possible plan:
>>> https://gist.github.com/Anton3/e00026409a6f948ca3ba41acf24e9672
>>>
>>> There is a base line of "core", control-like operators, which everyone
>>> must know. "Applied" operators are branched off them. For example, Ternary,
>>> Comparison or Casting can be selected as base for a new mini-tree of
>>> related operators.
>>>
>>> Following this scheme, there are at least 3 "applied" domains with
>>> operators: arithmetic, bitwise and range formation. You can see result in
>>> the gist.
>>>
>>
> Well, I don't suggest changing precedence relationships there (just
> removing some), so that should be on-topic, I guess?
>
> The main change I suggest over separating bitwise operators is separating
> RangeFormation, because it's a separate, "applied" operator domain. It is
> not control-structure-like, so it does not deserve to be in the main tree.
>
> Simplifying even more, I want to prohibit this:  a...b+c
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Improved value and move semantics

[Dave Abrahams via swift-evolution]

on Sun Jul 31 2016, Bram Beernink  wrote:

> Hi Karl and Haravikk,
>
> Thank you for your replies. 
>
> I was assuming that the cases I represented are not always optimized for 
> several reasons:
> Swift’s book only talks about optimization in the context of arrays,
> strings and dictionaries. Not in the context of structs in general:
> “The description above refers to the “copying” of strings, arrays, and
> dictionaries. The behavior you see in your code will always be as if a
> copy took place. However, Swift only performs an actual copy behind
> the scenes when it is absolutely necessary to do so. Swift manages all
> value copying to ensure optimal performance, 

If it says that, it's... not quite right.  There are things we could do
to make some value copies more optimal.  For example, any value type
containing multiple class references—or multiple other value types (such
as arrays or strings or dictionaries) that contain class references—will
cost more to copy than a single class reference does.  At the cost of
some allocation and indirection, we could reduce the copying cost of
such values.  It's an optimization we've considered making, but haven't
prioritized.  

You can put a CoW wrapper around your value to do it manually.  I hacked
one up using ManagedBuffer for someone at WWDC but I don't seem to have
saved the code, sadly.

> and you should not avoid assignment to try to preempt this
> optimization.”  

But that's basically still true.  The CoW wrapper technique is a good
way to tune things later if you find it necessary, without distorting
your code.

> Excerpt From: Apple Inc. “The Swift Programming Language (Swift 2.2).”
> iBooks. https://itun.es/nl/jEUH0.l  In
> https://github.com/apple/swift/tree/eb27bb65a7c17bd9b4255baee5c4e4f9c214bde6/stdlib/public/core
> 
> I see public mutating func append(_ newElement: Element) , line 1268,
> using _makeUniqueAndReserveCapacityIfNotUnique() at line 1269, leading
> me to suspect that to have COW, you have to do additional work.  Doing
> some manual tests some time ago, isUniquelyReferenced seemed to return
> false in a case like append_one as
> https://github.com/apple/swift/blob/master/docs/OptimizationTips.rst#advice-use-inplace-mutation-instead-of-object-reassignment
> 
> mentioned by Karl, meaning that it indeed leads to unnecessary
> copying.
>
> In any case,
> https://github.com/apple/swift/blob/master/docs/OptimizationTips.rst#advice-use-inplace-mutation-instead-of-object-reassignment
> 
> does mention that: “Sometimes COW can introduce additional unexpected
> copies if the user is not careful.” I would argue that what we need is
> not only COW, but Copy On Write When Necessary, COWWN. In COWWN copies
> are only made when writing to the shared reference if it is not unique
> and the shared reference’s old state is still referred to in next
> statements. 

That's what the standard library CoW types do currently, and yours can
too.  See isKnownUniquelyReferenced (née isUniquelyReferenced).

> So not only is the current reference count taken into account, but
> also whether the old state is needed afterwards. This is both runtime
> as well as compile-time data.
>
> So my questions would be:
> Why does Swift sometimes do additional unnecessary copying, as implied
> by
> https://github.com/apple/swift/blob/master/docs/OptimizationTips.rst#advice-use-inplace-mutation-instead-of-object-reassignment
> 
> in the case of append_one? 

In this case it could be needlessly copied because the optimizer is either 

a) off (-Onone)
b) not smart enough to know that `a` isn't used before being reassigned

> Is this a problem that cannot be solved?

I think this particular example can be solved.  There are other cases
where avoiding a needless copy is impossible due to the existence of a
separate compilation boundary (e.g. across frameworks, or files if
whole-module-optimization is disabled).

> (In C++ you would solve this example using
> a=a.append_one(std::move(a)). But I would think that since Swift does
> not have to deal with pointers and manual memory management, it can
> automatically detect such cases unlike C++?)  

In principle, yes.  In practice, it depends on visibility through
function call boundaries.

> If/once structs are COWWN, can Swift introduce immutable functions for
> the standard library, such as func appended(_ newElement: Element) ->
> Array?

That would be “appending.”  We could introduce that method 

Re: [swift-evolution] [Discussion] Breaking precedence

[Anton Zhilin via swift-evolution]

2016-08-02 21:56 GMT+03:00 Xiaodi Wu :

> I can sort of see what this is getting at, but I simply have no way of
> evaluating whether it's sensible or not without actual examples in code.
> This is, again, a more expansive change than discussed. I'd be interested
> in seeing your write-up on separating arithmetic and bitwise/bitshift
> operators :)
>
> On Tue, Aug 2, 2016 at 1:36 PM, Anton Zhilin 
> wrote:
>>
>> Here's another possible plan:
>> https://gist.github.com/Anton3/e00026409a6f948ca3ba41acf24e9672
>>
>> There is a base line of "core", control-like operators, which everyone
>> must know. "Applied" operators are branched off them. For example, Ternary,
>> Comparison or Casting can be selected as base for a new mini-tree of
>> related operators.
>>
>> Following this scheme, there are at least 3 "applied" domains with
>> operators: arithmetic, bitwise and range formation. You can see result in
>> the gist.
>>
>
Well, I don't suggest changing precedence relationships there (just
removing some), so that should be on-topic, I guess?

The main change I suggest over separating bitwise operators is separating
RangeFormation, because it's a separate, "applied" operator domain. It is
not control-structure-like, so it does not deserve to be in the main tree.

Simplifying even more, I want to prohibit this:  a...b+c
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

I can sort of see what this is getting at, but I simply have no way of
evaluating whether it's sensible or not without actual examples in code.
This is, again, a more expansive change than discussed. I'd be interested
in seeing your write-up on separating arithmetic and bitwise/bitshift
operators :)

On Tue, Aug 2, 2016 at 1:36 PM, Anton Zhilin  wrote:

> 2016-08-02 21:09 GMT+03:00 Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com>:
>
>> @Xiaodi
>> Actually, I think just about all the rest of the precedence rules “make
>> sense” intuitively:
>>
>> `a | b == c % d`
>> `a < b ? c : d * e`
>> `a ?? b - c`
>> `a...b+c`
>>
>> These all do what they ought to, and of course assignment naturally has
>> low precedence. Really the only confusing ones are operators that “seem
>> like peers” but actually have different precedences. Namely the two groups
>> I mentioned: logical operators and bitwise operators.
>>
>> @Daniel
>> Making it easy to write code that is unclear to other people who read it,
>> is an explicit anti-goal for Swift.
>>
>
> Here's another possible plan:
> https://gist.github.com/Anton3/e00026409a6f948ca3ba41acf24e9672
>
> There is a base line of "core", control-like operators, which everyone
> must know. "Applied" operators are branched off them. For example, Ternary,
> Comparison or Casting can be selected as base for a new mini-tree of
> related operators.
>
> Following this scheme, there are at least 3 "applied" domains with
> operators: arithmetic, bitwise and range formation. You can see result in
> the gist.
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Kevin Ballard via swift-evolution]

It did not eliminate that ability at all. You just need to say
`Swift.Error` instead of `Error` when referring to the protocol if a
nested `Error` type is in scope. For example:

class MyClass {
enum Error: Swift.Error {
case somethingWentWrong
}
}

-Kevin Ballard

On Tue, Aug 2, 2016, at 10:30 AM, Jon Shier via swift-evolution wrote:
> I’m not sure where to put such feedback, but the ErrorProtocol to
> Error rename that accompanied the implementation of this proposal is
> very, very painful. It completely eliminates the very useful ability
> to embed an associated Error type inside other types, as those types
> now conflict with the protocol. Also, was this rename accompanied by
> an evolution proposal? It seems like the change was just made when
> this proposal was implemented.
> Also, the adoption of this proposal by the Cocoa(Touch) frameworks as
> seen in Xcode 8 beta 4 has made asynchronous error handling quite a
> bit more arduous. For example, the CKDatabase method
> fetch(withRecordID recordID: CKRecordID, completionHandler:
> (CKRecord?, Error?) -> Void) returns an `Error` now, meaning I have to
> cast to the specific `CKError` type to get useful information out of
> it. Is this just an unfortunate first effort that will be fixed, or is
> this the expected form of these sorts of APIs after this proposal?
>
>
>
> Jon Shier
>
>
>> On Jul 12, 2016, at 8:44 AM, Shawn Erickson via swift-evolution > evolut...@swift.org> wrote:
>>
>> Thanks for the effort on the proposal and discussion and thanks to
>> those working in the implementation.
>>
>> -Shawn
>> On Tue, Jul 12, 2016 at 12:25 AM Charles Srstka via swift-evolution
>>  wrote:
>>> Wow, thanks! I’m delighted that Apple found this improvement to be
>>> worth inclusion in Swift 3. This will truly make the language much
>>> nicer to use with the Cocoa frameworks.
>>>
>>>  Thanks!
>>>
>>>  Charles
>>>
>>>  > On Jul 11, 2016, at 11:19 PM, Chris Lattner via swift-evolution
>>>  >  wrote:
>>>  >
>>>  > Proposal Link:
>>>  > 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md
>>>  >
>>>  > The review of "SE-0112: Improved NSError Bridging" ran from June
>>>  > 30 ... July 4, 2016. The proposal has been *accepted*:
>>>  >
>>>  > The community and core team agree that this proposal is a huge
>>>  > step forward that enriches the experience working with and
>>>  > extending the Cocoa NSError model in Swift.  The core team
>>>  > requests one minor renaming of
>>>  > "attemptRecovery(optionIndex:andThen:)" to
>>>  > "attemptRecovery(optionIndex:resultHandler:)”.  It also discussed
>>>  > renaming CustomNSError and RecoverableError, but decided to stay
>>>  > with those names.
>>>  >
>>>  > Thank you to Doug Gregor and Charles Srstka for driving this
>>>  > discussion forward, and for Doug Gregor taking the charge on the
>>>  > implementation effort to make this happen for Swift 3!
>>>  >
>>>  > -Chris Lattner
>>>  > Review Manager
>>>  >
>>>  > ___
>>>  > swift-evolution mailing list
>>>  > swift-evolution@swift.org
>>>  > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>  ___
>>>  swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Daniel Duan via swift-evolution]

> On Aug 2, 2016, at 11:09 AM, Nevin Brackett-Rozinsky 
>  wrote:
> 
> @Xiaodi
> Actually, I think just about all the rest of the precedence rules “make 
> sense” intuitively:
> 
> `a | b == c % d`
> `a < b ? c : d * e`
> `a ?? b - c`
> `a...b+c`
> 
> These all do what they ought to, and of course assignment naturally has low 
> precedence. Really the only confusing ones are operators that “seem like 
> peers” but actually have different precedences. Namely the two groups I 
> mentioned: logical operators and bitwise operators.
> 
> @Daniel
> Making it easy to write code that is unclear to other people who read it, is 
> an explicit anti-goal for Swift.
> 

Again, one’s “easy” might not apply to others, it’s easy *to him/her*. For 
people who intuitively pick out these precedences, extra parens is just noise 
that makes them second guess their understandings.

The goal we should pursue is *clarity*. Today, if one wants to emphasize the 
precedence, they can add parens anyways:  ` a || (b && c)`. But if we make `a 
|| b && c` have different meaning, that makes the code really really unclear 
(to the rest of us, who have assumptions about how precedences from our 
backgrounds) and will be a source for bugs. Assuming neither option is 
objectively better than the other, you need to convince us why the change is 
worth this cost.

> Nevin
> 
> 
> On Tue, Aug 2, 2016 at 1:42 PM, Xiaodi Wu  > wrote:
> This is an expansive argument you advance. Should users be expected to learn 
> *any* rules of precedence beyond those of basic arithmetic? It would seem 
> that you are arguing no. Yet Swift just went through an arduous redesign to 
> permit--nay, improve--exactly that.
> 
> On Tue, Aug 2, 2016 at 12:30 Nevin Brackett-Rozinsky 
> > 
> wrote:
> Speaking for myself, I will *never* remember which of `&&` and `||` has 
> higher precedence. I think of them as peers, so I always use parentheses 
> around them, and whenever I read code that mingles them without parentheses 
> its meaning is *unclear* to me.
> 
> One of Swift’s main goals is clarity at the point of use. After all, code is 
> read far more often than it is written. To me, an expression like `a && b || 
> c && d` is not clear when I read it.
> 
> The same goes for bitwise operators: I view them as peers. I do not think of 
> them as “additive” or “multiplicative” (and definitely not “subtractive”), so 
> code that relies on their precedences will always send me scrambling to look 
> up which comes first.
> 
> Certainly something like `a + b | c & d - e * f ^ g` is meaningless to me 
> without parentheses.
> 
> Nevin
> 
> 
> On Tue, Aug 2, 2016 at 12:08 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> That's an excellent point, actually. Would there be downsides not yet 
> considered?
> 
> 
> On Tue, Aug 2, 2016 at 11:03 Félix Cloutier  > wrote:
> These expressions mix two types of logic that have different implications. 
> For instance, `a * 16` and `a << 4` are "mostly equivalent", except that `a * 
> 16` will crash on overflow. In these cases, I find that grouping provides 
> some visual insulation that groups off the somewhat subtle differences.
> 
> Félix
> 
>> Le 2 août 2016 à 08:49:07, Xiaodi Wu > > a écrit :
>> 
>> On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier > > wrote:
>> I don't think that "intuitive" or "non-intuitive" is what you'd be looking 
>> for. There is nothing intuitive about multiplications having a higher 
>> precedence than additions; it's just a matter of conventions. I'm not a 
>> maths expert (as Stephen showed, I didn't even give the right explanation to 
>> binary operators!), but it seems to me that there could well be a parallel 
>> universe in which additions have precedence over multiplications without 
>> other serious implications.
>> 
>> And as it happens, a majority of people don't know that there is one for 
>> binary operators. I believe that the right question should be: do we want to 
>> pretend that this convention doesn't exist, to the benefit of people who 
>> don't know about it, and the detriment of those who do? Also, do we want to 
>> break it for && and || too?
>> 
>> I think that the biggest use case for binary operators in other languages 
>> are flags, and in Swift we treat these as collections. I'd venture that &, | 
>> and ^ would show up about as frequently as UnsafePointers and the like. It 
>> seems to me that Swift's approach has been to make things easy by default 
>> without locking away the power tools, and my personal expectation is that if 
>> you have to write code that has binary operators despite everything else 
>> that Swift has 

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

On Tue, Aug 2, 2016 at 1:07 PM, Anton Zhilin  wrote:

> 2016-08-02 19:08 GMT+03:00 Xiaodi Wu :
>
>> That's an excellent point, actually. Would there be downsides not yet
>> considered?
>>
>> On Tue, Aug 2, 2016 at 11:03 Félix Cloutier  wrote:
>>
>>> These expressions mix two types of logic that have different
>>> implications. For instance, `a * 16` and `a << 4` are "mostly equivalent",
>>> except that `a * 16` will crash on overflow. In these cases, I find that
>>> grouping provides some visual insulation that groups off the somewhat
>>> subtle differences.
>>>
>>> Félix
>>>
>>
> So it at least makes sense to create a proposal about this:
>
> RangeFormation < Addition < Multiplication
> RangeFormation < BitwiseOr < BitwiseAnd < BitwiseShift
>
> Pretty much everyone says that moving Ternary below Assignment would be a
> regression.
> I feel like a bit more discussion is needed on this:
>
> Another concern is NilCoalescing, which can be thought to be semantically
>> similar to Ternary. And at the same time it looks like || and &&, which
>> would bring it between LogicalConjunction and Comparison.
>> Also, do Casting and RangeFormation stand where they should?
>
>
> Someone said that this is actually not what was planned -- sure, it may
> need a separate proposal and a separate thread, but I think it's OK to use
> this one for now.
>

Anton, since this list is high-volume, people may skip entire conversations
because the subject line is not of interest to them. If you're going to
discuss additional topics, please do start new threads. That way, we can
get the maximum participation.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Anton Zhilin via swift-evolution]

2016-08-02 21:09 GMT+03:00 Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com>:

> @Xiaodi
> Actually, I think just about all the rest of the precedence rules “make
> sense” intuitively:
>
> `a | b == c % d`
> `a < b ? c : d * e`
> `a ?? b - c`
> `a...b+c`
>
> These all do what they ought to, and of course assignment naturally has
> low precedence. Really the only confusing ones are operators that “seem
> like peers” but actually have different precedences. Namely the two groups
> I mentioned: logical operators and bitwise operators.
>
> @Daniel
> Making it easy to write code that is unclear to other people who read it,
> is an explicit anti-goal for Swift.
>

Here's another possible plan:
https://gist.github.com/Anton3/e00026409a6f948ca3ba41acf24e9672

There is a base line of "core", control-like operators, which everyone must
know. "Applied" operators are branched off them. For example, Ternary,
Comparison or Casting can be selected as base for a new mini-tree of
related operators.

Following this scheme, there are at least 3 "applied" domains with
operators: arithmetic, bitwise and range formation. You can see result in
the gist.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

On Tue, Aug 2, 2016 at 1:09 PM, Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> @Xiaodi
> Actually, I think just about all the rest of the precedence rules “make
> sense” intuitively:
>

Disagree vehemently. See below:


> `a | b == c % d`
> `a < b ? c : d * e`
>

I, like you, know what this means; but it is out of habit, not intuition.
There have been people *on this very list* who have argued in the past that
ternary operator precedence is unintuitive and that parentheses should be
required. To them, the more intuitive (and counterfactual) meaning of the
above is`a < (b ? c : d) * e`.


> `a ?? b - c`
>

Here, I'm in the exact scenario you mentioned about bitwise operators. I
literally do not recall, staring at this statement, whether it's `(a ?? b)
- c` or `a ?? (b - c)`. I actually look this up every time.


> `a...b+c`
>
> These all do what they ought to, and of course assignment naturally has
> low precedence.
>

Naturally. Also, essentially how it works in math.


> Really the only confusing ones are operators that “seem like peers” but
> actually have different precedences. Namely the two groups I mentioned:
> logical operators and bitwise operators.
>

Which brings me to my original question: aren't you really saying that
people should not be required to *learn* any rules of precedence beyond
those of basic arithmetic? Put another way, unless you learned it in
elementary school math or can "intuit" the result--usually because the
alternative interpretations wouldn't even typecheck--then there should be
no precedence relationship?


>
> @Daniel
> Making it easy to write code that is unclear to other people who read it,
> is an explicit anti-goal for Swift.
>
> Nevin
>
>
> On Tue, Aug 2, 2016 at 1:42 PM, Xiaodi Wu  wrote:
>
>> This is an expansive argument you advance. Should users be expected to
>> learn *any* rules of precedence beyond those of basic arithmetic? It would
>> seem that you are arguing no. Yet Swift just went through an arduous
>> redesign to permit--nay, improve--exactly that.
>>
>> On Tue, Aug 2, 2016 at 12:30 Nevin Brackett-Rozinsky <
>> nevin.brackettrozin...@gmail.com> wrote:
>>
>>> Speaking for myself, I will *never* remember which of `&&` and `||` has
>>> higher precedence. I think of them as peers, so I always use parentheses
>>> around them, and whenever I read code that mingles them without parentheses
>>> its meaning is *unclear* to me.
>>>
>>> One of Swift’s main goals is clarity at the point of use. After all,
>>> code is read far more often than it is written. To me, an expression like
>>> `a && b || c && d` is not clear when I read it.
>>>
>>> The same goes for bitwise operators: I view them as peers. I do not
>>> think of them as “additive” or “multiplicative” (and definitely not
>>> “subtractive”), so code that relies on their precedences will always send
>>> me scrambling to look up which comes first.
>>>
>>> Certainly something like `a + b | c & d - e * f ^ g` is meaningless to
>>> me without parentheses.
>>>
>>> Nevin
>>>
>>>
>>> On Tue, Aug 2, 2016 at 12:08 PM, Xiaodi Wu via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 That's an excellent point, actually. Would there be downsides not yet
 considered?


 On Tue, Aug 2, 2016 at 11:03 Félix Cloutier  wrote:

> These expressions mix two types of logic that have different
> implications. For instance, `a * 16` and `a << 4` are "mostly equivalent",
> except that `a * 16` will crash on overflow. In these cases, I find that
> grouping provides some visual insulation that groups off the somewhat
> subtle differences.
>
> Félix
>
> Le 2 août 2016 à 08:49:07, Xiaodi Wu  a écrit :
>
> On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier 
> wrote:
>
>> I don't think that "intuitive" or "non-intuitive" is what you'd be
>> looking for. There is nothing intuitive about multiplications having a
>> higher precedence than additions; it's just a matter of conventions. I'm
>> not a maths expert (as Stephen showed, I didn't even give the right
>> explanation to binary operators!), but it seems to me that there could 
>> well
>> be a parallel universe in which additions have precedence over
>> multiplications without other serious implications.
>>
>> And as it happens, a majority of people don't know that there is one
>> for binary operators. I believe that the right question should be: do we
>> want to pretend that this convention doesn't exist, to the benefit of
>> people who don't know about it, and the detriment of those who do? Also, 
>> do
>> we want to break it for && and || too?
>>
>> I think that the biggest use case for binary operators in other
>> languages are flags, and in Swift we treat these as collections. I'd
>> venture that &, | and ^ would show up about as 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[David Owens II via swift-evolution]

And you go back to a single point of failure, requirement to host and maintain 
a server, or to pay them to host it for you.

Discourse is probably the best alternative, but it still has drawbacks as well.

-David


> On Aug 2, 2016, at 11:28 AM, Shawn Erickson via swift-evolution 
>  wrote:
> 
> Exactly. If you utilize a forum solution like Discourse you often will also 
> still be able to support folks that want to deal with email.
> 
> -Shawn
> 
> On Tue, Aug 2, 2016 at 11:17 AM Tim Vermeulen via swift-evolution 
> > wrote:
> For what it’s worth: Discourse has a Mailing List mode, which will send you 
> an email every time someone makes a new topic or replies to an existing topic 
> (apart from the topics you muted). You can then reply to that email to post a 
> reply in that topic, just like in a mailing list.
> 
> > On 8/2/16 13:15, Karl Wagner via swift-evolution wrote:
> > > There's no guarantee we would have to give it up entirely - many forum
> > > platforms have apps with caching for offline viewing.
> > >
> > > Besides, im not sure these discussions are always so important that you
> > > really need to download the entire list and save it all offline.
> > >
> > > Karl
> > >
> > > > On Aug 2, 2016 at 6:05 pm, > > >  > > > >>wrote:
> > > >
> > > > On 8/2/16 12:21, Erica Sadun via swift-evolution wrote:
> > > > > It is an instructive example of why remaining with a mailing list, 
> > > > > flaws and all, is probably the best answer for Swift Evolution.
> > > >
> > > > Whatever keeps a mailing list as bottom implementation gets my +1.
> > > > Forums and other browser-based things may be more convenient _if_ you're
> > > > in a place with 24/7 connectivity, which is not true for many.
> > > >
> > > > FWIW I'm using Thunderbird off the gmane group because threading doesn't
> > > > work well with other email clients.
> > A scenario I often have to follow, both at home and on trips, is
> > connect, download everything new, disconnect, read entire threads later
> > offline.
> >
> > --
> > Rainer Brockerhoff>
> > Belo Horizonte, Brazil
> > "In the affairs of others even fools are wise
> > In their own business even sages err."
> > http://brockerhoff.net/blog/ 
> >
> >
> >
> >
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Shawn Erickson via swift-evolution]

Exactly. If you utilize a forum solution like Discourse you often will also
still be able to support folks that want to deal with email.

-Shawn

On Tue, Aug 2, 2016 at 11:17 AM Tim Vermeulen via swift-evolution <
swift-evolution@swift.org> wrote:

> For what it’s worth: Discourse has a Mailing List mode, which will send
> you an email every time someone makes a new topic or replies to an existing
> topic (apart from the topics you muted). You can then reply to that email
> to post a reply in that topic, just like in a mailing list.
>
> > On 8/2/16 13:15, Karl Wagner via swift-evolution wrote:
> > > There's no guarantee we would have to give it up entirely - many forum
> > > platforms have apps with caching for offline viewing.
> > >
> > > Besides, im not sure these discussions are always so important that you
> > > really need to download the entire list and save it all offline.
> > >
> > > Karl
> > >
> > > > On Aug 2, 2016 at 6:05 pm, > > > >wrote:
> > > >
> > > > On 8/2/16 12:21, Erica Sadun via swift-evolution wrote:
> > > > > It is an instructive example of why remaining with a mailing list,
> flaws and all, is probably the best answer for Swift Evolution.
> > > >
> > > > Whatever keeps a mailing list as bottom implementation gets my +1.
> > > > Forums and other browser-based things may be more convenient _if_
> you're
> > > > in a place with 24/7 connectivity, which is not true for many.
> > > >
> > > > FWIW I'm using Thunderbird off the gmane group because threading
> doesn't
> > > > work well with other email clients.
> > A scenario I often have to follow, both at home and on trips, is
> > connect, download everything new, disconnect, read entire threads later
> > offline.
> >
> > --
> > Rainer Brockerhoff
> > Belo Horizonte, Brazil
> > "In the affairs of others even fools are wise
> > In their own business even sages err."
> > http://brockerhoff.net/blog/
> >
> >
> >
> >
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Tim Vermeulen via swift-evolution]

For what it’s worth: Discourse has a Mailing List mode, which will send you an 
email every time someone makes a new topic or replies to an existing topic 
(apart from the topics you muted). You can then reply to that email to post a 
reply in that topic, just like in a mailing list.

> On 8/2/16 13:15, Karl Wagner via swift-evolution wrote:
> > There's no guarantee we would have to give it up entirely - many forum
> > platforms have apps with caching for offline viewing.
> > 
> > Besides, im not sure these discussions are always so important that you
> > really need to download the entire list and save it all offline.
> > 
> > Karl
> > 
> > > On Aug 2, 2016 at 6:05 pm, > > >wrote:
> > > 
> > > On 8/2/16 12:21, Erica Sadun via swift-evolution wrote:
> > > > It is an instructive example of why remaining with a mailing list, 
> > > > flaws and all, is probably the best answer for Swift Evolution.
> > > 
> > > Whatever keeps a mailing list as bottom implementation gets my +1.
> > > Forums and other browser-based things may be more convenient _if_ you're
> > > in a place with 24/7 connectivity, which is not true for many.
> > > 
> > > FWIW I'm using Thunderbird off the gmane group because threading doesn't
> > > work well with other email clients.
> A scenario I often have to follow, both at home and on trips, is
> connect, download everything new, disconnect, read entire threads later
> offline.
> 
> --
> Rainer Brockerhoff
> Belo Horizonte, Brazil
> "In the affairs of others even fools are wise
> In their own business even sages err."
> http://brockerhoff.net/blog/
> 
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Anton Zhilin via swift-evolution]

2016-08-02 19:08 GMT+03:00 Xiaodi Wu :

> That's an excellent point, actually. Would there be downsides not yet
> considered?
>
> On Tue, Aug 2, 2016 at 11:03 Félix Cloutier  wrote:
>
>> These expressions mix two types of logic that have different
>> implications. For instance, `a * 16` and `a << 4` are "mostly equivalent",
>> except that `a * 16` will crash on overflow. In these cases, I find that
>> grouping provides some visual insulation that groups off the somewhat
>> subtle differences.
>>
>> Félix
>>
>
So it at least makes sense to create a proposal about this:

RangeFormation < Addition < Multiplication
RangeFormation < BitwiseOr < BitwiseAnd < BitwiseShift

Pretty much everyone says that moving Ternary below Assignment would be a
regression.
I feel like a bit more discussion is needed on this:

Another concern is NilCoalescing, which can be thought to be semantically
> similar to Ternary. And at the same time it looks like || and &&, which
> would bring it between LogicalConjunction and Comparison.
> Also, do Casting and RangeFormation stand where they should?


Someone said that this is actually not what was planned -- sure, it may
need a separate proposal and a separate thread, but I think it's OK to use
this one for now.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Nevin Brackett-Rozinsky via swift-evolution]

@Xiaodi
Actually, I think just about all the rest of the precedence rules “make
sense” intuitively:

`a | b == c % d`
`a < b ? c : d * e`
`a ?? b - c`
`a...b+c`

These all do what they ought to, and of course assignment naturally has low
precedence. Really the only confusing ones are operators that “seem like
peers” but actually have different precedences. Namely the two groups I
mentioned: logical operators and bitwise operators.

@Daniel
Making it easy to write code that is unclear to other people who read it,
is an explicit anti-goal for Swift.

Nevin


On Tue, Aug 2, 2016 at 1:42 PM, Xiaodi Wu  wrote:

> This is an expansive argument you advance. Should users be expected to
> learn *any* rules of precedence beyond those of basic arithmetic? It would
> seem that you are arguing no. Yet Swift just went through an arduous
> redesign to permit--nay, improve--exactly that.
>
> On Tue, Aug 2, 2016 at 12:30 Nevin Brackett-Rozinsky <
> nevin.brackettrozin...@gmail.com> wrote:
>
>> Speaking for myself, I will *never* remember which of `&&` and `||` has
>> higher precedence. I think of them as peers, so I always use parentheses
>> around them, and whenever I read code that mingles them without parentheses
>> its meaning is *unclear* to me.
>>
>> One of Swift’s main goals is clarity at the point of use. After all, code
>> is read far more often than it is written. To me, an expression like `a &&
>> b || c && d` is not clear when I read it.
>>
>> The same goes for bitwise operators: I view them as peers. I do not think
>> of them as “additive” or “multiplicative” (and definitely not
>> “subtractive”), so code that relies on their precedences will always send
>> me scrambling to look up which comes first.
>>
>> Certainly something like `a + b | c & d - e * f ^ g` is meaningless to me
>> without parentheses.
>>
>> Nevin
>>
>>
>> On Tue, Aug 2, 2016 at 12:08 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> That's an excellent point, actually. Would there be downsides not yet
>>> considered?
>>>
>>>
>>> On Tue, Aug 2, 2016 at 11:03 Félix Cloutier  wrote:
>>>
 These expressions mix two types of logic that have different
 implications. For instance, `a * 16` and `a << 4` are "mostly equivalent",
 except that `a * 16` will crash on overflow. In these cases, I find that
 grouping provides some visual insulation that groups off the somewhat
 subtle differences.

 Félix

 Le 2 août 2016 à 08:49:07, Xiaodi Wu  a écrit :

 On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier 
 wrote:

> I don't think that "intuitive" or "non-intuitive" is what you'd be
> looking for. There is nothing intuitive about multiplications having a
> higher precedence than additions; it's just a matter of conventions. I'm
> not a maths expert (as Stephen showed, I didn't even give the right
> explanation to binary operators!), but it seems to me that there could 
> well
> be a parallel universe in which additions have precedence over
> multiplications without other serious implications.
>
> And as it happens, a majority of people don't know that there is one
> for binary operators. I believe that the right question should be: do we
> want to pretend that this convention doesn't exist, to the benefit of
> people who don't know about it, and the detriment of those who do? Also, 
> do
> we want to break it for && and || too?
>
> I think that the biggest use case for binary operators in other
> languages are flags, and in Swift we treat these as collections. I'd
> venture that &, | and ^ would show up about as frequently as 
> UnsafePointers
> and the like. It seems to me that Swift's approach has been to make things
> easy by default without locking away the power tools, and my personal
> expectation is that if you have to write code that has binary operators
> despite everything else that Swift has for you, you can be bothered to
> learn a precedence rule.
>
> That said, one thing that I could definitely get behind is breaking
> precedence between binary operators and arithmetic operators. I don't 
> think
> that it makes sense to write something like "a & b / c". Looking at my
> code, the only place where I needed to mix binary operators and arithmetic
> operators were `a & (a - 1)` (results in 0 if a is a power of two), and
> that one needs parentheses anyway.
>

 Although here, your same argument applies. If you need to write `a & b
 / c`, then you can be bothered either to learn or look up a table, or you
 can just put in the parenthesis yourself. Likewise, if you're a reader of
 the code, it's highly likely that this is a complex formula anyway; you can
 either know the relative precedence or look it up, but that's the *least*
 of 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Rainer Brockerhoff via swift-evolution]

On 8/2/16 13:15, Karl Wagner via swift-evolution wrote:
> There's no guarantee we would have to give it up entirely - many forum
> platforms have apps with caching for offline viewing.
> 
> Besides, im not sure these discussions are always so important that you
> really need to download the entire list and save it all offline.
> 
> Karl
> 
>> On Aug 2, 2016 at 6:05 pm, > > wrote:
>>
>> On 8/2/16 12:21, Erica Sadun via swift-evolution wrote:
>> > It is an instructive example of why remaining with a mailing list, flaws 
>> > and all, is probably the best answer for Swift Evolution.
>>
>> Whatever keeps a mailing list as bottom implementation gets my +1.
>> Forums and other browser-based things may be more convenient _if_ you're
>> in a place with 24/7 connectivity, which is not true for many.
>>
>> FWIW I'm using Thunderbird off the gmane group because threading doesn't
>> work well with other email clients.

A scenario I often have to follow, both at home and on trips, is
connect, download everything new, disconnect, read entire threads later
offline.

-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

This is an expansive argument you advance. Should users be expected to
learn *any* rules of precedence beyond those of basic arithmetic? It would
seem that you are arguing no. Yet Swift just went through an arduous
redesign to permit--nay, improve--exactly that.
On Tue, Aug 2, 2016 at 12:30 Nevin Brackett-Rozinsky <
nevin.brackettrozin...@gmail.com> wrote:

> Speaking for myself, I will *never* remember which of `&&` and `||` has
> higher precedence. I think of them as peers, so I always use parentheses
> around them, and whenever I read code that mingles them without parentheses
> its meaning is *unclear* to me.
>
> One of Swift’s main goals is clarity at the point of use. After all, code
> is read far more often than it is written. To me, an expression like `a &&
> b || c && d` is not clear when I read it.
>
> The same goes for bitwise operators: I view them as peers. I do not think
> of them as “additive” or “multiplicative” (and definitely not
> “subtractive”), so code that relies on their precedences will always send
> me scrambling to look up which comes first.
>
> Certainly something like `a + b | c & d - e * f ^ g` is meaningless to me
> without parentheses.
>
> Nevin
>
>
> On Tue, Aug 2, 2016 at 12:08 PM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> That's an excellent point, actually. Would there be downsides not yet
>> considered?
>>
>>
>> On Tue, Aug 2, 2016 at 11:03 Félix Cloutier  wrote:
>>
>>> These expressions mix two types of logic that have different
>>> implications. For instance, `a * 16` and `a << 4` are "mostly equivalent",
>>> except that `a * 16` will crash on overflow. In these cases, I find that
>>> grouping provides some visual insulation that groups off the somewhat
>>> subtle differences.
>>>
>>> Félix
>>>
>>> Le 2 août 2016 à 08:49:07, Xiaodi Wu  a écrit :
>>>
>>> On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier 
>>> wrote:
>>>
 I don't think that "intuitive" or "non-intuitive" is what you'd be
 looking for. There is nothing intuitive about multiplications having a
 higher precedence than additions; it's just a matter of conventions. I'm
 not a maths expert (as Stephen showed, I didn't even give the right
 explanation to binary operators!), but it seems to me that there could well
 be a parallel universe in which additions have precedence over
 multiplications without other serious implications.

 And as it happens, a majority of people don't know that there is one
 for binary operators. I believe that the right question should be: do we
 want to pretend that this convention doesn't exist, to the benefit of
 people who don't know about it, and the detriment of those who do? Also, do
 we want to break it for && and || too?

 I think that the biggest use case for binary operators in other
 languages are flags, and in Swift we treat these as collections. I'd
 venture that &, | and ^ would show up about as frequently as UnsafePointers
 and the like. It seems to me that Swift's approach has been to make things
 easy by default without locking away the power tools, and my personal
 expectation is that if you have to write code that has binary operators
 despite everything else that Swift has for you, you can be bothered to
 learn a precedence rule.

 That said, one thing that I could definitely get behind is breaking
 precedence between binary operators and arithmetic operators. I don't think
 that it makes sense to write something like "a & b / c". Looking at my
 code, the only place where I needed to mix binary operators and arithmetic
 operators were `a & (a - 1)` (results in 0 if a is a power of two), and
 that one needs parentheses anyway.

>>>
>>> Although here, your same argument applies. If you need to write `a & b /
>>> c`, then you can be bothered either to learn or look up a table, or you can
>>> just put in the parenthesis yourself. Likewise, if you're a reader of the
>>> code, it's highly likely that this is a complex formula anyway; you can
>>> either know the relative precedence or look it up, but that's the *least*
>>> of your worries in terms of what it will take to understand that code. I
>>> see no reason to force parentheses unless it actually prevents user error.
>>>
>>>


 Félix

 Le 2 août 2016 à 02:29:41, Anton Zhilin  a
 écrit :

 2016-08-02 7:18 GMT+03:00 Félix Cloutier :

> I disagree. The binary operators have properties that are comparable
> to arithmetic operators, and their precedence is easy to define as such. &
> has multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has
> addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has
> subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their
> precedences are set 

Re: [swift-evolution] [Discussion] Breaking precedence

[Daniel Duan via swift-evolution]

> On Aug 2, 2016, at 10:30 AM, Nevin Brackett-Rozinsky via swift-evolution 
>  wrote:
> 
> Speaking for myself, I will *never* remember which of `&&` and `||` has 
> higher precedence.

I had the opposite experience. The point here is don’t rob others for our own 
conveniences, which are definitionally subjective.

> I think of them as peers, so I always use parentheses around them, and 
> whenever I read code that mingles them without parentheses its meaning is 
> *unclear* to me.
> 
> One of Swift’s main goals is clarity at the point of use. After all, code is 
> read far more often than it is written. To me, an expression like `a && b || 
> c && d` is not clear when I read it.
> 
> The same goes for bitwise operators: I view them as peers. I do not think of 
> them as “additive” or “multiplicative” (and definitely not “subtractive”), so 
> code that relies on their precedences will always send me scrambling to look 
> up which comes first.
> 
> Certainly something like `a + b | c & d - e * f ^ g` is meaningless to me 
> without parentheses.
> 
> Nevin
> 
> 
> 
> On Tue, Aug 2, 2016 at 12:08 PM, Xiaodi Wu via swift-evolution 
> > wrote:
> That's an excellent point, actually. Would there be downsides not yet 
> considered?
> 
> 
> On Tue, Aug 2, 2016 at 11:03 Félix Cloutier  > wrote:
> These expressions mix two types of logic that have different implications. 
> For instance, `a * 16` and `a << 4` are "mostly equivalent", except that `a * 
> 16` will crash on overflow. In these cases, I find that grouping provides 
> some visual insulation that groups off the somewhat subtle differences.
> 
> Félix
> 
>> Le 2 août 2016 à 08:49:07, Xiaodi Wu > > a écrit :
>> 
>> On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier > > wrote:
>> I don't think that "intuitive" or "non-intuitive" is what you'd be looking 
>> for. There is nothing intuitive about multiplications having a higher 
>> precedence than additions; it's just a matter of conventions. I'm not a 
>> maths expert (as Stephen showed, I didn't even give the right explanation to 
>> binary operators!), but it seems to me that there could well be a parallel 
>> universe in which additions have precedence over multiplications without 
>> other serious implications.
>> 
>> And as it happens, a majority of people don't know that there is one for 
>> binary operators. I believe that the right question should be: do we want to 
>> pretend that this convention doesn't exist, to the benefit of people who 
>> don't know about it, and the detriment of those who do? Also, do we want to 
>> break it for && and || too?
>> 
>> I think that the biggest use case for binary operators in other languages 
>> are flags, and in Swift we treat these as collections. I'd venture that &, | 
>> and ^ would show up about as frequently as UnsafePointers and the like. It 
>> seems to me that Swift's approach has been to make things easy by default 
>> without locking away the power tools, and my personal expectation is that if 
>> you have to write code that has binary operators despite everything else 
>> that Swift has for you, you can be bothered to learn a precedence rule.
>> 
>> That said, one thing that I could definitely get behind is breaking 
>> precedence between binary operators and arithmetic operators. I don't think 
>> that it makes sense to write something like "a & b / c". Looking at my code, 
>> the only place where I needed to mix binary operators and arithmetic 
>> operators were `a & (a - 1)` (results in 0 if a is a power of two), and that 
>> one needs parentheses anyway.
>> 
>> Although here, your same argument applies. If you need to write `a & b / c`, 
>> then you can be bothered either to learn or look up a table, or you can just 
>> put in the parenthesis yourself. Likewise, if you're a reader of the code, 
>> it's highly likely that this is a complex formula anyway; you can either 
>> know the relative precedence or look it up, but that's the *least* of your 
>> worries in terms of what it will take to understand that code. I see no 
>> reason to force parentheses unless it actually prevents user error.
>>  
>> 
>> 
>> Félix
>> 
>>> Le 2 août 2016 à 02:29:41, Anton Zhilin >> > a écrit :
>>> 
>>> 2016-08-02 7:18 GMT+03:00 Félix Cloutier >> >:
>>> I disagree. The binary operators have properties that are comparable to 
>>> arithmetic operators, and their precedence is easy to define as such. & has 
>>> multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has 
>>> addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has 
>>> subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their 
>>> 

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

[Jon Shier via swift-evolution]

I’m not sure where to put such feedback, but the ErrorProtocol to Error 
rename that accompanied the implementation of this proposal is very, very 
painful. It completely eliminates the very useful ability to embed an 
associated Error type inside other types, as those types now conflict with the 
protocol. Also, was this rename accompanied by an evolution proposal? It seems 
like the change was just made when this proposal was implemented.
Also, the adoption of this proposal by the Cocoa(Touch) frameworks as 
seen in Xcode 8 beta 4 has made asynchronous error handling quite a bit more 
arduous. For example, the CKDatabase method fetch(withRecordID recordID: 
CKRecordID, completionHandler: (CKRecord?, Error?) -> Void) returns an `Error` 
now, meaning I have to cast to the specific `CKError` type to get useful 
information out of it. Is this just an unfortunate first effort that will be 
fixed, or is this the expected form of these sorts of APIs after this proposal?



Jon Shier


> On Jul 12, 2016, at 8:44 AM, Shawn Erickson via swift-evolution 
>  wrote:
> 
> Thanks for the effort on the proposal and discussion and thanks to those 
> working in the implementation.
> 
> -Shawn
> On Tue, Jul 12, 2016 at 12:25 AM Charles Srstka via swift-evolution 
> > wrote:
> Wow, thanks! I’m delighted that Apple found this improvement to be worth 
> inclusion in Swift 3. This will truly make the language much nicer to use 
> with the Cocoa frameworks.
> 
> Thanks!
> 
> Charles
> 
> > On Jul 11, 2016, at 11:19 PM, Chris Lattner via swift-evolution 
> > > wrote:
> >
> > Proposal Link: 
> > https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md
> >  
> > 
> >
> > The review of "SE-0112: Improved NSError Bridging" ran from June 30 ... 
> > July 4, 2016. The proposal has been *accepted*:
> >
> > The community and core team agree that this proposal is a huge step forward 
> > that enriches the experience working with and extending the Cocoa NSError 
> > model in Swift.  The core team requests one minor renaming of 
> > "attemptRecovery(optionIndex:andThen:)" to 
> > "attemptRecovery(optionIndex:resultHandler:)”.  It also discussed renaming 
> > CustomNSError and RecoverableError, but decided to stay with those names.
> >
> > Thank you to Doug Gregor and Charles Srstka for driving this discussion 
> > forward, and for Doug Gregor taking the charge on the implementation effort 
> > to make this happen for Swift 3!
> >
> > -Chris Lattner
> > Review Manager
> >
> > ___
> > swift-evolution mailing list
> > swift-evolution@swift.org 
> > https://lists.swift.org/mailman/listinfo/swift-evolution 
> > 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Nevin Brackett-Rozinsky via swift-evolution]

Speaking for myself, I will *never* remember which of `&&` and `||` has
higher precedence. I think of them as peers, so I always use parentheses
around them, and whenever I read code that mingles them without parentheses
its meaning is *unclear* to me.

One of Swift’s main goals is clarity at the point of use. After all, code
is read far more often than it is written. To me, an expression like `a &&
b || c && d` is not clear when I read it.

The same goes for bitwise operators: I view them as peers. I do not think
of them as “additive” or “multiplicative” (and definitely not
“subtractive”), so code that relies on their precedences will always send
me scrambling to look up which comes first.

Certainly something like `a + b | c & d - e * f ^ g` is meaningless to me
without parentheses.

Nevin



On Tue, Aug 2, 2016 at 12:08 PM, Xiaodi Wu via swift-evolution <
swift-evolution@swift.org> wrote:

> That's an excellent point, actually. Would there be downsides not yet
> considered?
>
>
> On Tue, Aug 2, 2016 at 11:03 Félix Cloutier  wrote:
>
>> These expressions mix two types of logic that have different
>> implications. For instance, `a * 16` and `a << 4` are "mostly equivalent",
>> except that `a * 16` will crash on overflow. In these cases, I find that
>> grouping provides some visual insulation that groups off the somewhat
>> subtle differences.
>>
>> Félix
>>
>> Le 2 août 2016 à 08:49:07, Xiaodi Wu  a écrit :
>>
>> On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier 
>> wrote:
>>
>>> I don't think that "intuitive" or "non-intuitive" is what you'd be
>>> looking for. There is nothing intuitive about multiplications having a
>>> higher precedence than additions; it's just a matter of conventions. I'm
>>> not a maths expert (as Stephen showed, I didn't even give the right
>>> explanation to binary operators!), but it seems to me that there could well
>>> be a parallel universe in which additions have precedence over
>>> multiplications without other serious implications.
>>>
>>> And as it happens, a majority of people don't know that there is one for
>>> binary operators. I believe that the right question should be: do we want
>>> to pretend that this convention doesn't exist, to the benefit of people who
>>> don't know about it, and the detriment of those who do? Also, do we want to
>>> break it for && and || too?
>>>
>>> I think that the biggest use case for binary operators in other
>>> languages are flags, and in Swift we treat these as collections. I'd
>>> venture that &, | and ^ would show up about as frequently as UnsafePointers
>>> and the like. It seems to me that Swift's approach has been to make things
>>> easy by default without locking away the power tools, and my personal
>>> expectation is that if you have to write code that has binary operators
>>> despite everything else that Swift has for you, you can be bothered to
>>> learn a precedence rule.
>>>
>>> That said, one thing that I could definitely get behind is breaking
>>> precedence between binary operators and arithmetic operators. I don't think
>>> that it makes sense to write something like "a & b / c". Looking at my
>>> code, the only place where I needed to mix binary operators and arithmetic
>>> operators were `a & (a - 1)` (results in 0 if a is a power of two), and
>>> that one needs parentheses anyway.
>>>
>>
>> Although here, your same argument applies. If you need to write `a & b /
>> c`, then you can be bothered either to learn or look up a table, or you can
>> just put in the parenthesis yourself. Likewise, if you're a reader of the
>> code, it's highly likely that this is a complex formula anyway; you can
>> either know the relative precedence or look it up, but that's the *least*
>> of your worries in terms of what it will take to understand that code. I
>> see no reason to force parentheses unless it actually prevents user error.
>>
>>
>>>
>>>
>>> Félix
>>>
>>> Le 2 août 2016 à 02:29:41, Anton Zhilin  a
>>> écrit :
>>>
>>> 2016-08-02 7:18 GMT+03:00 Félix Cloutier :
>>>
 I disagree. The binary operators have properties that are comparable to
 arithmetic operators, and their precedence is easy to define as such. & has
 multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has
 addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has
 subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their
 precedences are set accordingly (& is multiplicative, | and ^ are 
 additive).

 The same applies to && and ||. Bit shifts are exponentiative.

>>>
>>> I believe that such way of thinking is non-intuitive. In C, bitwise
>>> operators are not intervened by any others, except for comparison operators
>>> (agreed, it was a mistake). We now have possibilities to do so in Swift,
>>> even better. I suggest to branch off right before AdditionPrecedence:
>>>
>>> RangeFormation < 

[swift-evolution] [final revision] SE-0117: Allow distinguishing between public access and public overridability

[John McCall via swift-evolution]

> On Jul 27, 2016, at 3:06 PM, Chris Lattner  wrote:
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md
> 
> The third review of "SE-0177: Allow distinguishing between public access and 
> public overridability" ran from Active review July 21...25. The proposal has 
> been *accepted with revisions*.
> 
> This proposal was far better received by the community than previous versions 
> of the proposal, and the “first design” was the favored path within it.  
> However, there were some concerns raised about the complexity of the model, 
> stemming from non-obvious combinations like “open private”.  As such, the 
> core team has requested that the proposal be revised to make “open” function 
> as another access control specifier.  “open” is now simply “more public than 
> public”, providing a very simple and clean model.
> 
> John has already revised the proposal to the new model, I encourage you to 
> read it if you haven’t already.
> 
> Thank you to John McCall and also Javier Soto for driving this discussion 
> forward!  John is already working on an implementation of this now.

I'm resurrecting this thread to point out some minor revisions / clarifications 
that came up during implementation.

The first is that the accepted proposal contained "temporary" restrictions that 
required (1) open classes to subclass open classes and (2) open methods to 
override open methods.  (2) is actually inconsistent with our existing 
access-control rules about overrides: the overridden method doesn't even have 
to be public.  Making a method open in a subclass shouldn't force you to expose 
it in your superclass.  Therefore, we have lifted this restriction.  (1) is 
consistent with the access control rule on subclasses, so it has been 
conservatively kept; we're still open to reconsidering this in the future.

The second is that the proposal wasn't clear about how open interacts with 
initializers.  There are many things about our current class-initialization 
design that are unsatisfactory, but we are not going to fix them in Swift 3.  
However, as a general matter, the clearest mental model for initializers is 
that every class provides its own, independent interface for constructing 
complete-objects / base-subobjects of that class.  The initializers in each 
class are formally distinct from the initializers in their subclasses, even 
when they happen to have the same signature; they are not in any real sense 
"overrides" (even if in some cases we do currently require the "override" 
keyword).  This is true even for required initializers, which merely state a 
requirement that all subclasses must provide a complete-object initializer with 
a particular signature, rather than expressing a real relationship between 
those initializers at each level.  Furthermore, it is understood that 
constructing an object of a subclass necessarily involves delegating to that 
subclass; subclasses must always be able to initialize their portions of 
constructed objects.  For all of these reasons, it is correct for initializers 
to not participate in open checking: they cannot be declared open, but 
correspondingly there are no restrictions on what initializers can be defined 
in a subclass, even if they have the same signature as an initializer from a 
superclass.

I have updated the proposal to reflect this.

John.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift Generics: connection between equality constraints on generic parameters and GADTs

[Douglas Gregor via swift-evolution]

> On Aug 2, 2016, at 9:36 AM, Gabriel Scherer  wrote:
> 
> I'm not familiar with Swift, but happened to find the Generics
> Manifesto document at
>  https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
> 
> I wonder if the Swift community is aware of the strong connection
> between equalities on generic type parameters of the form "where T ==
> Foo" in method or extension declarations, and the Generalized
> Algebraic Datatypes (GADTs) of the functional programming community.
> To my knowledge, this relation has first been established in the 2006
> article "Generalized Algebraic Data Types and Object-Oriented
> Programming", by Andrew Kennedy and Claudio Russo, that contain
> examples that you might find interesting:
>  
> https://www.microsoft.com/en-us/research/publication/generalized-algebraic-data-types-and-object-oriented-programming/
> 
> There has been a lot of work on GADTs and their expressiveness in the
> functional programming community, and I think that realizing the
> connection could be helpful for some further generics language design.


There are some in the Swift community that have a deep interest in and 
understanding of type theory. However, as a general rule, we try to keep the 
Swift language—and discussions of its evolution—accessible to everyone. One 
should not need to have a copy of TAPL on their desk to participate in the 
discussions here, and if an idea isn’t presented in the context of how it can 
improve Swift directly (with specific motivating code examples written in 
Swift), it’s really not relevant to the discussion.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

[Muse M via swift-evolution]

I'm concern if simd could improve factorials code and faster timing.

import simd
func factorial(n: Int) -> Int {
return n < 1 ? 1 : n * factorial(n: n - 1)
}
print(factorial(n: 40))

On Wed, Aug 3, 2016 at 12:00 AM, Charlie Monroe 
wrote:

> That's a good point. :)
>
> On Aug 2, 2016, at 5:55 PM, Xiaodi Wu  wrote:
>
> I'm going to guess, since Musa mentioned science and engineering, that a
> good chunk of that work is floating point :)
>
>
> On Tue, Aug 2, 2016 at 10:41 AM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Are you using the variants of operators without overflow check? I.e.
>>
>> let num = a &+ b // [1]
>>
>> [1]
>> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
>>
>>
>>
>> On Aug 2, 2016, at 3:01 AM, Muse M  wrote:
>>
>> Have always wonder why Maths in Swift is slower than C and Go, it should
>> be address with priority if Swift is to be adopt for engineering, financial
>> and science industry.
>>
>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> See
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>>
>>> From what I understand, the discussion should stay focused on the main
>>> topics for Swift 4 that Chris highlighted in
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>>
>>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>>> the schedule...
>>>
>>>
>>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> It was stated that 27th of July was the last date for proposal
>>> acceptance, 29th of July was the last day for implementation, and 1th of
>>> August should be the starting day of Swift 3.1-related discussions.
>>> Am I right? Should we begin?
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

[Charlie Monroe via swift-evolution]

That's a good point. :)

> On Aug 2, 2016, at 5:55 PM, Xiaodi Wu  wrote:
> 
> I'm going to guess, since Musa mentioned science and engineering, that a good 
> chunk of that work is floating point :)
> 
> 
> On Tue, Aug 2, 2016 at 10:41 AM, Charlie Monroe via swift-evolution 
> > wrote:
> Are you using the variants of operators without overflow check? I.e.
> 
> let num = a &+ b // [1]
> 
> [1] 
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
>  
> 
> 
> 
> 
>> On Aug 2, 2016, at 3:01 AM, Muse M > > wrote:
>> 
>> Have always wonder why Maths in Swift is slower than C and Go, it should be 
>> address with priority if Swift is to be adopt for engineering, financial and 
>> science industry.
>> 
>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
>> > wrote:
>> See 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>  
>> 
>> 
>> From what I understand, the discussion should stay focused on the main 
>> topics for Swift 4 that Chris highlighted in 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>  
>> 
>> 
>> I had several ideas in mind, but am postponing them for Swift 5, seeing the 
>> schedule...
>> 
>> 
>>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
>>> > wrote:
>>> 
>>> It was stated that 27th of July was the last date for proposal acceptance, 
>>> 29th of July was the last day for implementation, and 1th of August should 
>>> be the starting day of Swift 3.1-related discussions.
>>> Am I right? Should we begin?
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Karl Wagner via swift-evolution]

 
 
There's   no guarantee we would have to give it up entirely - many forum 
platforms have apps with caching for offline viewing.
 
 
 
 Besides, im not sure these discussions are always so important that you really 
need to download the entire list and save it all offline.
 
 
 
 Karl
 

 
 Sent from my new   Email 
(https://itunes.apple.com/app/apple-store/id922793622?pt=814382=8=my_new_email)
 
 
 
 

 
 
>  
> On Aug 2, 2016 at 6:05 pm,   (mailto:swift-evolution@swift.org)>  wrote:
>  
>  
>  
>  On 8/2/16 12:21, Erica Sadun via swift-evolution wrote:
> >  It is an instructive example of why remaining with a mailing list, flaws 
> > and all, is probably the best answer for Swift Evolution.
>
> Whatever keeps a mailing list as bottom implementation gets my +1.
> Forums and other browser-based things may be more convenient _if_ you're
> in a place with 24/7 connectivity, which is not true for many.
>
> FWIW I'm using Thunderbird off the gmane group because threading doesn't
> work well with other email clients.
>
> -- 
> Rainer Brockerhoff  
> Belo Horizonte, Brazil
> "In the affairs of others even fools are wise
> In their own business even sages err."
> http://brockerhoff.net/blog/ 
> (http://brockerhoff.net/blog/___swift-evolution)
>
> ___ 
> (http://brockerhoff.net/blog/___swift-evolution)
> swift-evolution 
> (http://brockerhoff.net/blog/___swift-evolution)
>   mailing  list (mailto:listswift-evolution@swift.orghttps)
> swift-evolution@swift.org (mailto:listswift-evolution@swift.orghttps)
> https 
> (mailto:listswift-evolution@swift.orghttps)://lists.swift.org/mailman/listinfo/swift-evolution
>  ___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Tino Heth via swift-evolution]

> It is an instructive example of why remaining with a mailing list, flaws and 
> all, is probably the best answer for Swift Evolution.
I don't get this:
If Swift Evolution had been using something more versatile than mailing lists, 
there wouldn't have been the need to use Gmane, which just helped to work 
around limitations of the original medium.
For me, it's just an argument to not switch to something that is controlled by 
a third party.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

That's an excellent point, actually. Would there be downsides not yet
considered?

On Tue, Aug 2, 2016 at 11:03 Félix Cloutier  wrote:

> These expressions mix two types of logic that have different implications.
> For instance, `a * 16` and `a << 4` are "mostly equivalent", except that `a
> * 16` will crash on overflow. In these cases, I find that grouping provides
> some visual insulation that groups off the somewhat subtle differences.
>
> Félix
>
> Le 2 août 2016 à 08:49:07, Xiaodi Wu  a écrit :
>
> On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier  wrote:
>
>> I don't think that "intuitive" or "non-intuitive" is what you'd be
>> looking for. There is nothing intuitive about multiplications having a
>> higher precedence than additions; it's just a matter of conventions. I'm
>> not a maths expert (as Stephen showed, I didn't even give the right
>> explanation to binary operators!), but it seems to me that there could well
>> be a parallel universe in which additions have precedence over
>> multiplications without other serious implications.
>>
>> And as it happens, a majority of people don't know that there is one for
>> binary operators. I believe that the right question should be: do we want
>> to pretend that this convention doesn't exist, to the benefit of people who
>> don't know about it, and the detriment of those who do? Also, do we want to
>> break it for && and || too?
>>
>> I think that the biggest use case for binary operators in other languages
>> are flags, and in Swift we treat these as collections. I'd venture that &,
>> | and ^ would show up about as frequently as UnsafePointers and the like.
>> It seems to me that Swift's approach has been to make things easy by
>> default without locking away the power tools, and my personal expectation
>> is that if you have to write code that has binary operators despite
>> everything else that Swift has for you, you can be bothered to learn a
>> precedence rule.
>>
>> That said, one thing that I could definitely get behind is breaking
>> precedence between binary operators and arithmetic operators. I don't think
>> that it makes sense to write something like "a & b / c". Looking at my
>> code, the only place where I needed to mix binary operators and arithmetic
>> operators were `a & (a - 1)` (results in 0 if a is a power of two), and
>> that one needs parentheses anyway.
>>
>
> Although here, your same argument applies. If you need to write `a & b /
> c`, then you can be bothered either to learn or look up a table, or you can
> just put in the parenthesis yourself. Likewise, if you're a reader of the
> code, it's highly likely that this is a complex formula anyway; you can
> either know the relative precedence or look it up, but that's the *least*
> of your worries in terms of what it will take to understand that code. I
> see no reason to force parentheses unless it actually prevents user error.
>
>
>>
>>
>> Félix
>>
>> Le 2 août 2016 à 02:29:41, Anton Zhilin  a écrit
>> :
>>
>> 2016-08-02 7:18 GMT+03:00 Félix Cloutier :
>>
>>> I disagree. The binary operators have properties that are comparable to
>>> arithmetic operators, and their precedence is easy to define as such. & has
>>> multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has
>>> addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has
>>> subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their
>>> precedences are set accordingly (& is multiplicative, | and ^ are additive).
>>>
>>> The same applies to && and ||. Bit shifts are exponentiative.
>>>
>>
>> I believe that such way of thinking is non-intuitive. In C, bitwise
>> operators are not intervened by any others, except for comparison operators
>> (agreed, it was a mistake). We now have possibilities to do so in Swift,
>> even better. I suggest to branch off right before AdditionPrecedence:
>>
>> RangeFormation < Addition < Multiplication
>> RangeFormation < BitwiseOr < BitwiseAnd < LogicalShift
>>
>> Another concern is NilCoalescing, which can be though to be semantically
>> similar to Ternary. And at the same time it looks like || and &&, which
>> would bring it between LogicalConjunction and Comparison.
>> Also, do Casting and RangeFormation stand where they should?
>>
>> Next, Ternary operator is unique. Noone would ever like to put operators
>> in this precedence group, because it would be confusing. Why not simplify
>> our model and say that ?: has lower precedence than all binary operators,
>> including Assignment? Unary > binary > ternary, sounds good?
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Rainer Brockerhoff via swift-evolution]

On 8/2/16 12:21, Erica Sadun via swift-evolution wrote:
> It is an instructive example of why remaining with a mailing list, flaws and 
> all, is probably the best answer for Swift Evolution.

Whatever keeps a mailing list as bottom implementation gets my +1.
Forums and other browser-based things may be more convenient _if_ you're
in a place with 24/7 connectivity, which is not true for many.

FWIW I'm using Thunderbird off the gmane group because threading doesn't
work well with other email clients.

-- 
Rainer Brockerhoff  
Belo Horizonte, Brazil
"In the affairs of others even fools are wise
In their own business even sages err."
http://brockerhoff.net/blog/

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Félix Cloutier via swift-evolution]

These expressions mix two types of logic that have different implications. For 
instance, `a * 16` and `a << 4` are "mostly equivalent", except that `a * 16` 
will crash on overflow. In these cases, I find that grouping provides some 
visual insulation that groups off the somewhat subtle differences.

Félix

> Le 2 août 2016 à 08:49:07, Xiaodi Wu  a écrit :
> 
> On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier  > wrote:
> I don't think that "intuitive" or "non-intuitive" is what you'd be looking 
> for. There is nothing intuitive about multiplications having a higher 
> precedence than additions; it's just a matter of conventions. I'm not a maths 
> expert (as Stephen showed, I didn't even give the right explanation to binary 
> operators!), but it seems to me that there could well be a parallel universe 
> in which additions have precedence over multiplications without other serious 
> implications.
> 
> And as it happens, a majority of people don't know that there is one for 
> binary operators. I believe that the right question should be: do we want to 
> pretend that this convention doesn't exist, to the benefit of people who 
> don't know about it, and the detriment of those who do? Also, do we want to 
> break it for && and || too?
> 
> I think that the biggest use case for binary operators in other languages are 
> flags, and in Swift we treat these as collections. I'd venture that &, | and 
> ^ would show up about as frequently as UnsafePointers and the like. It seems 
> to me that Swift's approach has been to make things easy by default without 
> locking away the power tools, and my personal expectation is that if you have 
> to write code that has binary operators despite everything else that Swift 
> has for you, you can be bothered to learn a precedence rule.
> 
> That said, one thing that I could definitely get behind is breaking 
> precedence between binary operators and arithmetic operators. I don't think 
> that it makes sense to write something like "a & b / c". Looking at my code, 
> the only place where I needed to mix binary operators and arithmetic 
> operators were `a & (a - 1)` (results in 0 if a is a power of two), and that 
> one needs parentheses anyway.
> 
> Although here, your same argument applies. If you need to write `a & b / c`, 
> then you can be bothered either to learn or look up a table, or you can just 
> put in the parenthesis yourself. Likewise, if you're a reader of the code, 
> it's highly likely that this is a complex formula anyway; you can either know 
> the relative precedence or look it up, but that's the *least* of your worries 
> in terms of what it will take to understand that code. I see no reason to 
> force parentheses unless it actually prevents user error.
>  
> 
> 
> Félix
> 
>> Le 2 août 2016 à 02:29:41, Anton Zhilin > > a écrit :
>> 
>> 2016-08-02 7:18 GMT+03:00 Félix Cloutier > >:
>> I disagree. The binary operators have properties that are comparable to 
>> arithmetic operators, and their precedence is easy to define as such. & has 
>> multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has 
>> addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has 
>> subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their 
>> precedences are set accordingly (& is multiplicative, | and ^ are additive).
>> 
>> The same applies to && and ||. Bit shifts are exponentiative.
>> 
>> I believe that such way of thinking is non-intuitive. In C, bitwise 
>> operators are not intervened by any others, except for comparison operators 
>> (agreed, it was a mistake). We now have possibilities to do so in Swift, 
>> even better. I suggest to branch off right before AdditionPrecedence:
>> 
>> RangeFormation < Addition < Multiplication
>> RangeFormation < BitwiseOr < BitwiseAnd < LogicalShift
>> 
>> Another concern is NilCoalescing, which can be though to be semantically 
>> similar to Ternary. And at the same time it looks like || and &&, which 
>> would bring it between LogicalConjunction and Comparison.
>> Also, do Casting and RangeFormation stand where they should?
>> 
>> Next, Ternary operator is unique. Noone would ever like to put operators in 
>> this precedence group, because it would be confusing. Why not simplify our 
>> model and say that ?: has lower precedence than all binary operators, 
>> including Assignment? Unary > binary > ternary, sounds good? 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Multi dimensional - iterator, Iterator2D, Iterator3D

[Ted F.A. van Gaalen via swift-evolution]

Hi Garth

> I’m not sure why you’re trying to avoid sequences - as far as the actual 
> values you are iterating over, your needs seem to be pretty well covered by 
> the existing stride() family.

 I am not avoiding per se the use of Strides & Sequence & Co.
 It is just because I simply don’t need them in my iterator functions.
> 
> Given that you just want to flatten the call sites, perhaps something like 
> this would suit your needs:
> 
> let xrange = stride(from:  0.0, to: 30.0, by: 10.0)
> let yrange = stride(from:  0.0, to: 20.0, by: 5.0)
> let zrange = stride(from: 10.0, to:-10.0, by:-5.0)
> 
> for (x, y, z) in cartesianProduct(xrange, yrange, zrange) {
>print("x = \(x) y = \(y) z = \(z)")
>if z < 0.0 {
>print ( "** z value \(z) is below zero! **" )
>break
>}
> }
> Using strides removes the need for any of the NumericType labels, and 
> cartesianProduct() would be usable for any (reiterable) sequences, not just 
> your designated types. 

True. but what I have now works. all I need was new iterators for numeric type 
as soon as possible 
because the for;; will be no longer available in 3.0.
As a sort of spin-off I also made it for 2 and 3 dimensions.
For my apps this is sufficient and even better to use than the nested 
for;;for;; 

I am currently trying to write an iterator that should work
with a variable depth of levels. A recursive approach
Currently it is under construction not yet working as expected.
I cannot wrap my brain around the recursive part. (yet)
will drop it for a day or two. :o) 
You can try / improve it in your xcode playground if you like. is 2.3 but 
should also work in 3.0.

struct IteratorParameters
{
let start: T
let step:  T
let test: (T) -> Bool
}

func iterateR( parameters: [IteratorParameters], block: 
(Int,[T]) -> Bool)
{
var currents = [T]()
for parm in parameters
{
currents.append(parm.start)   // initialize current values with start 
values.
}

let levels = parameters.count - 1
var level  = 0

//——under constructionobviously still not ok 
here---
func iterateLevel()  // recursive nested function.
{

while parameters[level].test(currents[level]) && block(level,currents)
{
currents[level] = currents[level] + parameters[level].step
iterateLevel()  // recursive
}
level = level + 1
print("\n")
}

//---
iterateLevel()
}


func testIteratorR()
{

var itparms = [IteratorParameters]()

itparms.append( IteratorParameters( start: 0, step :1, test: {$0 <  3} 
) )
itparms.append( IteratorParameters( start: 0, step :1, test: {$0 <  3} 
) )
itparms.append( IteratorParameters( start: 0, step :1, test: {$0 <  3} 
) )
itparms.append( IteratorParameters( start: 0, step :1, test: {$0 <  3} 
) )

iterateR(itparms,
 block: {lvl, values in
 print("level=\(lvl) values = \(values)")
   return true} )
}


> 
> If you want a language issue to obsess over, I suggest the inflexibility of 
> tuples, which force you to have a separate wrapper for each number of 
> dimensions. :-)
 :o) I find very little use for tuples, except perhaps when tuples are used to 
pass byte arrays to lower-level functions, and even then.
I am more and more less “obsessed” with changing and disappearing  language 
features, because 
in many cases, in Swift increasingly you can roll your own to replace them or 
even make something better, if really needed.
like in Smalltalk as well. 
> 
> I would have thought there’d be an off-the-shelf cartesian product somewhere 
> that you could use, but it doesn’t seem to come up in the Google. It’d look 
> something like this. (This is causing a compiler crash in Xcode 8b3 and so is 
> not completely vetted, but it’s probably close…)

Will try your solution (looks clever)  although I don’t need the collection 
“by-product”  Perhaps more suited for
in progs that have a more functional programming inclination?
> 
> func cartesianProduct(_ 
> args: U...) ->
>AnyIterator<[V]>
> {
>var iterators = args.map { $0.makeIterator() }
>var values = [V?]()
>for i in 0 ... iterators.endIndex {
>values.append(iterators[i].next())
>}
>var done = values.contains { $0 == nil }
> 
>return AnyIterator() {
>if done {
>return nil
>}
>let thisValue = values.map { $0! }
>var i = args.endIndex
>repeat {
>values[i] = iterators[i].next()
>if values[i] != nil {
>return thisValue
>} else if i == 0 {
>done = true
>return thisValue
>} else {
>iterators[i] = args[i].makeIterator()
>

Re: [swift-evolution] Swift 3.1 discussions, go?

[Xiaodi Wu via swift-evolution]

I'm going to guess, since Musa mentioned science and engineering, that a
good chunk of that work is floating point :)


On Tue, Aug 2, 2016 at 10:41 AM, Charlie Monroe via swift-evolution <
swift-evolution@swift.org> wrote:

> Are you using the variants of operators without overflow check? I.e.
>
> let num = a &+ b // [1]
>
> [1]
> https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
>
>
>
> On Aug 2, 2016, at 3:01 AM, Muse M  wrote:
>
> Have always wonder why Maths in Swift is slower than C and Go, it should
> be address with priority if Swift is to be adopt for engineering, financial
> and science industry.
>
> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> See
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>
>> From what I understand, the discussion should stay focused on the main
>> topics for Swift 4 that Chris highlighted in
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>
>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>> the schedule...
>>
>>
>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It was stated that 27th of July was the last date for proposal
>> acceptance, 29th of July was the last day for implementation, and 1th of
>> August should be the starting day of Swift 3.1-related discussions.
>> Am I right? Should we begin?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Xiaodi Wu via swift-evolution]

On Tue, Aug 2, 2016 at 10:41 AM, Félix Cloutier  wrote:

> I don't think that "intuitive" or "non-intuitive" is what you'd be looking
> for. There is nothing intuitive about multiplications having a higher
> precedence than additions; it's just a matter of conventions. I'm not a
> maths expert (as Stephen showed, I didn't even give the right explanation
> to binary operators!), but it seems to me that there could well be a
> parallel universe in which additions have precedence over multiplications
> without other serious implications.
>
> And as it happens, a majority of people don't know that there is one for
> binary operators. I believe that the right question should be: do we want
> to pretend that this convention doesn't exist, to the benefit of people who
> don't know about it, and the detriment of those who do? Also, do we want to
> break it for && and || too?
>
> I think that the biggest use case for binary operators in other languages
> are flags, and in Swift we treat these as collections. I'd venture that &,
> | and ^ would show up about as frequently as UnsafePointers and the like.
> It seems to me that Swift's approach has been to make things easy by
> default without locking away the power tools, and my personal expectation
> is that if you have to write code that has binary operators despite
> everything else that Swift has for you, you can be bothered to learn a
> precedence rule.
>
> That said, one thing that I could definitely get behind is breaking
> precedence between binary operators and arithmetic operators. I don't think
> that it makes sense to write something like "a & b / c". Looking at my
> code, the only place where I needed to mix binary operators and arithmetic
> operators were `a & (a - 1)` (results in 0 if a is a power of two), and
> that one needs parentheses anyway.
>

Although here, your same argument applies. If you need to write `a & b /
c`, then you can be bothered either to learn or look up a table, or you can
just put in the parenthesis yourself. Likewise, if you're a reader of the
code, it's highly likely that this is a complex formula anyway; you can
either know the relative precedence or look it up, but that's the *least*
of your worries in terms of what it will take to understand that code. I
see no reason to force parentheses unless it actually prevents user error.


>
>
> Félix
>
> Le 2 août 2016 à 02:29:41, Anton Zhilin  a écrit :
>
> 2016-08-02 7:18 GMT+03:00 Félix Cloutier :
>
>> I disagree. The binary operators have properties that are comparable to
>> arithmetic operators, and their precedence is easy to define as such. & has
>> multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has
>> addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has
>> subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their
>> precedences are set accordingly (& is multiplicative, | and ^ are additive).
>>
>> The same applies to && and ||. Bit shifts are exponentiative.
>>
>
> I believe that such way of thinking is non-intuitive. In C, bitwise
> operators are not intervened by any others, except for comparison operators
> (agreed, it was a mistake). We now have possibilities to do so in Swift,
> even better. I suggest to branch off right before AdditionPrecedence:
>
> RangeFormation < Addition < Multiplication
> RangeFormation < BitwiseOr < BitwiseAnd < LogicalShift
>
> Another concern is NilCoalescing, which can be though to be semantically
> similar to Ternary. And at the same time it looks like || and &&, which
> would bring it between LogicalConjunction and Comparison.
> Also, do Casting and RangeFormation stand where they should?
>
> Next, Ternary operator is unique. Noone would ever like to put operators
> in this precedence group, because it would be confusing. Why not simplify
> our model and say that ?: has lower precedence than all binary operators,
> including Assignment? Unary > binary > ternary, sounds good?
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

[Charlie Monroe via swift-evolution]

Are you using the variants of operators without overflow check? I.e.

let num = a &+ b // [1]

[1] 
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AdvancedOperators.html
 




> On Aug 2, 2016, at 3:01 AM, Muse M  wrote:
> 
> Have always wonder why Maths in Swift is slower than C and Go, it should be 
> address with priority if Swift is to be adopt for engineering, financial and 
> science industry.
> 
> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution 
> > wrote:
> See 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>  
> 
> 
> From what I understand, the discussion should stay focused on the main topics 
> for Swift 4 that Chris highlighted in 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>  
> 
> 
> I had several ideas in mind, but am postponing them for Swift 5, seeing the 
> schedule...
> 
> 
>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution 
>> > wrote:
>> 
>> It was stated that 27th of July was the last date for proposal acceptance, 
>> 29th of July was the last day for implementation, and 1th of August should 
>> be the starting day of Swift 3.1-related discussions.
>> Am I right? Should we begin?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Félix Cloutier via swift-evolution]

I don't think that "intuitive" or "non-intuitive" is what you'd be looking for. 
There is nothing intuitive about multiplications having a higher precedence 
than additions; it's just a matter of conventions. I'm not a maths expert (as 
Stephen showed, I didn't even give the right explanation to binary operators!), 
but it seems to me that there could well be a parallel universe in which 
additions have precedence over multiplications without other serious 
implications.

And as it happens, a majority of people don't know that there is one for binary 
operators. I believe that the right question should be: do we want to pretend 
that this convention doesn't exist, to the benefit of people who don't know 
about it, and the detriment of those who do? Also, do we want to break it for 
&& and || too?

I think that the biggest use case for binary operators in other languages are 
flags, and in Swift we treat these as collections. I'd venture that &, | and ^ 
would show up about as frequently as UnsafePointers and the like. It seems to 
me that Swift's approach has been to make things easy by default without 
locking away the power tools, and my personal expectation is that if you have 
to write code that has binary operators despite everything else that Swift has 
for you, you can be bothered to learn a precedence rule.

That said, one thing that I could definitely get behind is breaking precedence 
between binary operators and arithmetic operators. I don't think that it makes 
sense to write something like "a & b / c". Looking at my code, the only place 
where I needed to mix binary operators and arithmetic operators were `a & (a - 
1)` (results in 0 if a is a power of two), and that one needs parentheses 
anyway.

Félix

> Le 2 août 2016 à 02:29:41, Anton Zhilin  a écrit :
> 
> 2016-08-02 7:18 GMT+03:00 Félix Cloutier  >:
> I disagree. The binary operators have properties that are comparable to 
> arithmetic operators, and their precedence is easy to define as such. & has 
> multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has 
> addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has subtraction-like 
> properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their precedences are set 
> accordingly (& is multiplicative, | and ^ are additive).
> 
> The same applies to && and ||. Bit shifts are exponentiative.
> 
> I believe that such way of thinking is non-intuitive. In C, bitwise operators 
> are not intervened by any others, except for comparison operators (agreed, it 
> was a mistake). We now have possibilities to do so in Swift, even better. I 
> suggest to branch off right before AdditionPrecedence:
> 
> RangeFormation < Addition < Multiplication
> RangeFormation < BitwiseOr < BitwiseAnd < LogicalShift
> 
> Another concern is NilCoalescing, which can be though to be semantically 
> similar to Ternary. And at the same time it looks like || and &&, which would 
> bring it between LogicalConjunction and Comparison.
> Also, do Casting and RangeFormation stand where they should?
> 
> Next, Ternary operator is unique. Noone would ever like to put operators in 
> this precedence group, because it would be confusing. Why not simplify our 
> model and say that ?: has lower precedence than all binary operators, 
> including Assignment? Unary > binary > ternary, sounds good? 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Swift 3.1 discussions, go?

[Xiaodi Wu via swift-evolution]

Already filed as SR-2247, complete with XCode project and performance test
:)

Jordan Rose was kind enough to duplicate it into Radar as well.

On Tue, Aug 2, 2016 at 09:44 Mark Lacey  wrote:

>
> On Aug 2, 2016, at 07:38, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I'd like to echo Muse's point. Accelerate is no solution: it's not
> available on Linux (and cross-platform numerics is very much essential for
> the sciences--I assume engineering and finance as well); moreover, it
> doesn't solve the issue of, as you point out, other kinds of math.
>
> The appeal to me of Swift was that it promised a memory-safe-by-default
> systems programming language, a compiled language with performance that can
> be in the same ballpark as C. So while specialized libraries like BLAS can
> speed up matrix algebra considerably, IMO, the same kinds of math that are
> done in C or Go or Rust without calling BLAS should perform roughly
> equivalently when ported to Swift. That it doesn't should be a bug, and the
> workaround shouldn't have to be dropping down to or calling out to
> libraries written in C or Fortran.
>
> Recently, I discovered that a straightforward numerics algorithm that only
> adds, divides, multiplies, and compares floating point values slowed down
> five to ten *times* between preview 3 and preview 4.
>
>
> Can you open a bug at bugs.swift.org and include a test case that can be
> compiled and executed to demonstrate the issue?
>
> Mark
>
> This was stunning--and if performance ever was comparable to C before (I
> didn't check for this particular function), I know for sure that it isn't
> anymore! Although I'm confident that the underlying cause will be found, it
> does raise questions as to the continued wisdom of writing even somewhat
> performance-sensitive math in Swift.
> On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> Well, it depends on what kind of Math you’re trying to do. The Accelerate
>> framework is available if you need performance.
>>
>> Saagar Jha
>>
>>
>>
>> On Aug 1, 2016, at 18:01, Muse M via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Have always wonder why Maths in Swift is slower than C and Go, it should
>> be address with priority if Swift is to be adopt for engineering, financial
>> and science industry.
>>
>> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> See
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>>
>>> From what I understand, the discussion should stay focused on the main
>>> topics for Swift 4 that Chris highlighted in
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>>
>>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>>> the schedule...
>>>
>>>
>>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> It was stated that 27th of July was the last date for proposal
>>> acceptance, 29th of July was the last day for implementation, and 1th of
>>> August should be the starting day of Swift 3.1-related discussions.
>>> Am I right? Should we begin?
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [META] Gmane and Swift Evolution

[Erica Sadun via swift-evolution]

On Aug 1, 2016, at 12:46 PM, Krishna Kumar  wrote:
> 
> Hey
> 
> I’ll update (SE0017 - SE0045)
> 
> Thanks
> 
> -Krishna

Thanks.

Remaining links as of this morning are listed below. Anyone willing to adopt a 
proposal or a group and get them updated, please reply in-thread and submit a 
PR with changes.

Tips: 

* Ideally, each proposal should have a link to a rationale, to on-list 
discussion(s), and review discussion(s). If any of these are missing, please 
add.
* Rationales are easily found on the announcement list: 
https://lists.swift.org/pipermail/swift-evolution-announce/ 

* Discussion and review threads need to be from the non-announce list to allow 
readers to follow the conversation.
* A few proposals are sourced from build-dev and not Swift Evolution
* The toughest updates were from December, before the archiving, formatting, 
etc got underway. Later links are a lot easier to track down.
* You cannot use Google to search for gmane threads as the site was set for no 
robots and there is no Internet Archive Wayback fallback. 

-- E


proposals/0030-property-behavior-decls.md:* Status: **Rejected** 
([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/7735))
proposals/0030-property-behavior-decls.md:[Swift Evolution 
Discussion](http://thread.gmane.org/gmane.comp.lang.swift.evolution/11976)
proposals/0030-property-behavior-decls.md:[Review](http://thread.gmane.org/gmane.comp.lang.swift.evolution/6426)
proposals/0031-adjusting-inout-declarations.md:* Status: **Accepted for Swift 
3** ([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/7394))
proposals/0031-adjusting-inout-declarations.md:*The initial Swift-Evolution 
discussion of this topic took place in the "[Replace 'inout' with 
&](http://comments.gmane.org/gmane.comp.lang.swift.evolution/2751)" thread.*
proposals/0032-sequencetype-find.md:* Status: **Accepted for Swift 3** 
([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/16116))
proposals/0033-import-objc-constants.md:* Status: **Implemented in Swift 3** 
([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/8817))
proposals/0034-disambiguating-line.md:* Status: **Accepted** 
([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/8156), 
[Implementation Bug](https://bugs.swift.org/browse/SR-840))
proposals/0034-disambiguating-line.md:The discussion took place on-line in the 
[*\[Discussion\]: Renaming #line, the line control 
statement*](http://comments.gmane.org/gmane.comp.lang.swift.evolution/5815) 
thread.
proposals/0035-limit-inout-capture.md:* Status: **Accepted** 
([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/7732), 
[Bug](https://bugs.swift.org/browse/SR-807))
proposals/0036-enum-dot.md:*Discussion took place on the Swift Evolution 
mailing list in the [\[Discussion\] Enum Leading Dot 
Prefixes](http://article.gmane.org/gmane.comp.lang.swift.evolution/6684) 
thread. This proposal uses lowerCamelCase enumeration cases in compliance with
proposals/0036-enum-dot.md:current [API Guideline Working Group 
guidance](http://news.gmane.org/gmane.comp.lang.swift.evolution).*
proposals/0037-clarify-comments-and-operators.md:* Status: **Accepted** 
([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/12350), 
[Bug](https://bugs.swift.org/browse/SR-960))
proposals/0037-clarify-comments-and-operators.md:Swift-evolution thread: 
[started here](http://thread.gmane.org/gmane.comp.lang.swift.evolution/605)
proposals/0037-clarify-comments-and-operators.md:and [continued 
here](http://thread.gmane.org/gmane.comp.lang.swift.evolution/2855).
proposals/0038-swiftpm-c-language-targets.md:[Swift Evolution Review 
Thread](http://thread.gmane.org/gmane.comp.lang.swift.evolution/7293)
proposals/0039-playgroundliterals.md:* Status: **Accepted** 
([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/9149/), 
[Bug](https://bugs.swift.org/browse/SR-917))
proposals/0039-playgroundliterals.md:*Discussion took place on the Swift 
Evolution mailing list in the [\[Discussion\] Modernizing Playground 
Literals](http://article.gmane.org/gmane.comp.lang.swift.evolution/7124) 
thread. Thanks to [Chris Lattner](https://github.com/lattner) for suggesting 
this enhancement.*
proposals/0045-scan-takewhile-dropwhile.md:* Status: **Accepted for Swift 3** 
([Rationale](http://thread.gmane.org/gmane.comp.lang.swift.evolution/16119), 
[Bug](https://bugs.swift.org/browse/SR-1516))
proposals/0045-scan-takewhile-dropwhile.md:[Proposal: Add scan, takeWhile, 
dropWhile, and iterate to the 
stdlib](http://thread.gmane.org/gmane.comp.lang.swift.evolution/1515)
proposals/0045-scan-takewhile-dropwhile.md:[rationale]: 
http://article.gmane.org/gmane.comp.lang.swift.evolution/16119
proposals/0076-copying-to-unsafe-mutable-pointer-with-unsafe-pointer-source.md:*
 Status: **Accepted with Revisions for Swift 3** 

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Karl via swift-evolution]

> On 2 Aug 2016, at 11:07, Tino Heth via swift-evolution 
>  wrote:
> 
>> I would love to have a great web archive for swift-evolution—something with 
>> a really solid search function, good threading, and most of the other 
>> niceties of forums. It'd even be nice to have an upvote feature. But these 
>> are all things that you could do without taking swift-evolution off of email.
> afair, the option of keeping a mail interface was mentioned in one of the 
> first posts, so none of the positive aspects of email would be lost (it just 
> wouldn't be possible to use the "bonus-features" that aren't available in the 
> medium)
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

The reason I don’t like mailing lists is because nobody has a good web UI for 
them. Gmane is clunky, the thing we have on lists.swift.org 
 is awful — it’s incredibly hard to follow 
conversations, things are separated by week/month for some reason, making 
searching difficult (and making it harder to follow the conversation). None of 
them allow messaging from the UI, or PM-ing a particular person if you discover 
their post some months later and want to ask a follow-up. It’s so far behind 
where group collaboration is today it’s not even funny. Then, of course, you’re 
exposing your email address on a public forum. So you either need a good spam 
filter or a second email address. Every other kind of forum abstracts your 
identity and puts a couple of spam-limiting barriers between strangers on the 
internet and your inbox.

The “advantage” of a mailing list - that you use your email client often, is 
pretty weak. For almost everybody, the browser can beat their mail client for 
usage hands-down. Everybody is used to the idea of having particular tabs which 
you always go back to - Apple even introduced “pinned tabs” in Safari for 
exactly that. If having it separate from the browser is also a bigger concern 
over all of email’s disadvantages, many forums have native applications 
available (e.g. Slack) or JSON interfaces, with apps already compatible with 
them and the ability to read offline.

Ditching email is obvious. It’s like if you discovered Elon Musk rode to work 
on a Penny-farthing.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [META] Gmane and Swift Evolution

[Ben Rimmington via swift-evolution]

> On 2 Aug 2016, at 16:16, Erica Sadun via swift-evolution 
>  wrote:
> 
> Anyone willing to adopt a proposal or a group and get them updated, please 
> reply in-thread and submit a PR with changes.

[SE-0076 ... SE-0090] 

-- Ben

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Erica Sadun via swift-evolution]

> On Aug 2, 2016, at 9:04 AM, Brad Hilton via swift-evolution 
>  wrote:
>> On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via 
>> swift-evolutionwrote:
>>> On Jul 29, 2016, at 5:14 PM, Brandon 
>>> Knopewrote:
 Forums for contributors would:
 - be more familiar for a lot of the newer and not as experienced developers
 - be easier to search
 - be easier to moderate (not really a problem yet)
>>> 
>>> Hi Brandon,
>>> 
>>> Moving from email to a forum system has come up before, but they have some 
>>> disadvantages.One of major wins of email is that it is pervasive and can be 
>>> adapted into other forms.For example, if you haven’t seen it yet, check out:
>>> https://stylemac.com/hirundo/
>>> 
>>> -Chris
>>> 
>> We've discussed forums on swift-evolution before. Maybe it's time for 
>> another go, with Swift 3 winding down.
>> 
>> For context, prior discussions are on this 
>> thread:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
>> 
>> I'd just like to vote once again 
>> forDiscourse(http://www.discourse.org/faq/#what):-Excellent web 
>> interface(https://meta.discourse.org/), from the people who brought you 
>> Stack Overflow(built-in search, etc.)
>> - Read via email if that's your thing: it has "mailing list mode" which 
>> includes 1-email-per-post, if that's your cup of tea
>> -Reply via 
>> email(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)if 
>> that's your thing
>> - It'sopen source(https://github.com/discourse/discourse)itself
>> - I believe it has ways of getting content as JSON and/or RSS, so I'd hardly 
>> say "can be adapted into other forms" is an exclusive feature of email.
>> 

> +1. I would love to see Swift Evolution on Slack or a forum, it would be so 
> much easier to manage.


Apologies for cross-thread posting but if anyone reading this thread can hop 
over to " [META] Gmane and Swift Evolution" and help the effort to recover from 
depending on a third party service, it will be greatly appreciated. It is an 
instructive example of why remaining with a mailing list, flaws and all, is 
probably the best answer for Swift Evolution.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [swift-users] Multi dimensional - iterator, Iterator2D, Iterator3D

[Ted F.A. van Gaalen via swift-evolution]

> On 01.08.2016, at 17:45, Saagar Jha  wrote:
> 
> With your method, don't you need to write a new method for every dimension?
Hi Saagar,

Yes, one could solve this by writing a function
that propagates though all iteration levels, possibly recursively,
I might try to implement that.
left “as an exercise to the astute reader” :o)   

Kind regards
Ted


> On Mon, Aug 1, 2016 at 08:43 Ted F.A. van Gaalen via swift-users 
> > wrote:
> Hi Erica
> 
> That would also be a workable solution, but imho still too tedious as 
> it has been so for many years, with nested iteration statements…
> many times this is for;; for;; for tables and for;;for;;for;; for 3D 
> structuring.
>   
> 
> Swift offers nice features (like protocols and generics as you know) to 
> improve this. 
> 
> - I no longer have to nest for;; s  so, Now I rather do this:  
> Your example can already be coded like this:
> 
>iterate2D( 1, 2, { $0 < 64 } ,
>   1, 2, { $0 < 64 } ,
>   {outerIndex,innerIndex in
>   print (outerIndex,InnerIndex)
>   
>   return true // Obligatory. return “false" to break
>}  )
> 
> With no chances in Swift, this already works like a charm!
> Imho much more readable and compact,
> 
> Uses - AFAICS from a programmers’s perspective - no 
> underlying deep collection based coding with Sequence. etc.
> 
> I am already deploying it in my own apps e.g. l
> (replaced for;; for;; for;; in the app)  
> 
> By using this new iterator…() functions my coding gets leaner 
> and errors are easier to spot. 
> 
> Actual working code with Swift 2.x here: 
> 
>   func generateTiles()
>   {
> let w:  Float =   20  // tile size
> let h:  Float =5
> let l:  Float =5
> 
> let xstart: Float = -120
> let ystart: Float =  -60
> let zstart: Float =  -10
> 
> let xend: Float = 120
> let yend: Float =  60
> let zend: Float =  10
> 
> let tolerance:Float = 0.001 // float drift compensation
> 
> iterate3D( xstart, w * 1.2, { $0 < xend + tolerance } ,
>ystart, h * 1.2, { $0 < yend + tolerance } ,
>zstart, l * 1.2, { $0 < zend + tolerance } ,
>{
> x,y,z in
> self.addTile(x,y,z,  
>  w,h,l)
> return true
>}  )
> }
> 
> This generates a group of blocks or tiles in my Apple TV app (under 
> construction)
> like the one you can see  in the image “Cloinckz” on my website www.tedvg.com 
> .
> 
> I also prefer the one dimensional iterate(..  too above the for;; or stride()
> 
> One could extend these iterator…() functions by adding closures for pre and 
> post iteration handling,
> like for printing headers and footers before and/or after a complete [inner] 
> iteration.
> 
> Note that breaking with *return false* -which is equivalent to the “break” 
> stmt in
> a classical for;; -  does not only leave a nested iteration, but also the 
> outer ones.
> (maybe a TODO to make individual level- break possible)  As it is now, If one 
> wants to break at the deep iteration level, then one should nest this using 
> 1D iterators.
> 
> 
> Anyway, this is just a thought starting to think about multi-dimensional 
> iterators,
> and other (encapsulation?) of multi dimensional data as well.
> In any case for 2D because table data is used very frequently in many apps. as
> most data are in tables.
> 
> You won’t believe this :o) but in a sense I might not make so much fuzz 
> anymore
> to keep the for;;  as this proves to me that I can solve things much better 
> that I thought.
> So, I have to rethink this.
> 
> Kind Regards
> Ted  
> www.ravelnotes.com 
> 
>  
> 
> 
> 
> 
> 
>> On 31.07.2016, at 18:33, Erica Sadun > > wrote:
>> 
>> I'm replying on Swift-Users and bcc'ing in Swift-Evolution to comply with 
>> the core team's request to focus SE on the current mission statement. 
>> 
>> At some point soon, Russ Bishop's PR 
>> https://github.com/apple/swift/pull/3600 
>>  will be incorporated into Swift 
>> 3. This PR adds `prefix(while:)` and `drop(while:)` to finish implementing 
>> SE-0045.  Once that's done, you can  combine `sequence(first:, next:)` and 
>> `prefix(while:)` to into a single function `sequence(first:, next:, while:)` 
>> like this:
>> 
>> public func sequence(first: T, next: (T) -> T?, while test: (T) -> Bool) 
>> -> UnfoldSequence> {
>> return sequence(first: first, next: next).prefix(while: test)
>> }
>> 
>> The combined sequence/prefix call allows you to create loops like 

Re: [swift-evolution] [Discussion] Breaking precedence

[Stephen Canon via swift-evolution]

> On Aug 2, 2016, at 12:18 AM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> I disagree. The binary operators have properties that are comparable to 
> arithmetic operators, and their precedence is easy to define as such. & has 
> multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has 
> addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has subtraction-like 
> properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their precedences are set 
> accordingly (& is multiplicative, | and ^ are additive).


`^` is actually the *addition* operator on Boolean rings[1].  `x | y` 
corresponds to the Boolean ring operation `x + y + xy`, which is definitely 
“addition-like” but isn’t addition.


Otherwise, spot on.

– Steve

[1] Of course, it’s *also* the subtraction operator, because `x = -x` for all 
members `x` of a Boolean ring (https://en.wikipedia.org/wiki/Boolean_ring 
), but one usually calls it 
“addition".___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Swift4] Mailing list vs. Forum

[Brad Hilton via swift-evolution]

+1. I would love to see Swift Evolution on Slack or a forum, it would be so 
much easier to manage.

Brad

> Branching...
> 
> On Fri, Jul 29, 2016 at 5:22 PM, Chris Lattner via 
> swift-evolutionwrote:
> > On Jul 29, 2016, at 5:14 PM, Brandon 
> > Knopewrote:
> > >
> > >Chris, has the core team discussed opening up a forum for discussing 
> > >proposal implementations.
> > >
> > >Some of us aren't as skilled as the core team or other contributors but 
> > >would like to learn. A forum is a much easier place for us to post for 
> > >code help and to help others with their questions. I think this could help 
> > >get more involved as it would be a more comfortable format for them. Think 
> > >of how there are Apple Developer forums and not mailing lists for iOS 
> > >betas etc.
> > >
> > >I am not saying moving swift-evo to forums *yet* but I believe a lot of 
> > >the newer programmers are more comfortable with a forum format, especially 
> > >when it comes to help and discussing code.
> > >
> > >Forums for contributors would:
> > >- be more familiar for a lot of the newer and not as experienced developers
> > >- be easier to search
> > >- be easier to moderate (not really a problem yet)
> > 
> > Hi Brandon,
> > 
> > Moving from email to a forum system has come up before, but they have some 
> > disadvantages.One of major wins of email is that it is pervasive and can be 
> > adapted into other forms.For example, if you haven’t seen it yet, check out:
> > https://stylemac.com/hirundo/
> > 
> > -Chris
> > 
> We've discussed forums on swift-evolution before. Maybe it's time for another 
> go, with Swift 3 winding down.
> 
> For context, prior discussions are on this 
> thread:https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001537.html
> 
> (-1 for mailman: it's hard for me to even properly find to all the prior 
> discussion about mailing lists, because of how mailman's archive works...)
> 
> 
> News in the last few days is that Gmane is at least temporarily 
> disappearing:https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/comment-page-1/#comment-13502
> 
> 
> I'd just like to vote once again 
> forDiscourse(http://www.discourse.org/faq/#what):-Excellent web 
> interface(https://meta.discourse.org/), from the people who brought you Stack 
> Overflow(built-in search, etc.)
> - Read via email if that's your thing: it has "mailing list mode" which 
> includes 1-email-per-post, if that's your cup of tea
> -Reply via 
> email(https://meta.discourse.org/t/replacing-mailing-lists-email-in/13099)if 
> that's your thing
> - It'sopen source(https://github.com/discourse/discourse)itself
> - I believe it has ways of getting content as JSON and/or RSS, so I'd hardly 
> say "can be adapted into other forms" is an exclusive feature of email.
> 
> And, Discourse providesfree hosting for community-friendly open-source 
> projects(http://blog.discourse.org/2016/03/free-discourse-forum-hosting-for-community-friendly-github-projects/).
>  Istrongly 
> suspect(https://twitter.com/jtbandes/status/705886542309363712)Swift would 
> qualify for this.
> 
> 
> There have been several people on this list arguing in favor of mailing lists 
> — I encourage folks to go read the old thread for themselves.
> 
> It's worth noting there are also plenty of voices that don't get heard on 
> this list, because people just don't like using mailing lists. One 
> example:https://twitter.com/pilky/status/755105431555608580___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] [Manifesto] Completing Generics

[Patrick Lind via swift-evolution]

Sorry about dredging up an older topic! I was trying to search through the
mailing list to figure out the right place to reference and this seemed as
good as any... Also this is the first mailing list I've ever joined and
first e-mail on said list so please forgive me if I'm doing this wrong!

I wanted to ask a question on the future of doing Protocol-oriented
programming in conjunction with generics. Disclosure, I've worked a lot
with C# so this would be the same idea as Interface oriented programming in
combination with Generics there.

Is there currently a way to do dependency injection using protocols with
generics? I've linked to a StackOverflow question below that I've asked
regarding this topic (again if that is a faux pas I apologize).

http://stackoverflow.com/questions/38619660/is-it-possible-to-pass-generic-protocols-into-a-constructor-for-proper-dependenc

The main aspect that I'm interested in getting to is being able to properly
mock and unit test my code using dependency injection and Protocols. This
is a very, very useful way to architect your code in such a way as to
easily facilitate this kind of unit testing in conjunction with Mocking.

Please let me know if I'm completely missing the boat here!

Thanks,

Patrick

> Hi all,
>
> Introduction
>
> The “Complete Generics” goal for Swift 3 has been fairly ill-defined thus
fair, with just this short blurb in the list of goals:
>
> Complete generics: Generics are used pervasively in a number of Swift
libraries, especially the standard library. However, there are a number of
generics features the standard library requires to fully realize its
vision, including recursive protocol constraints, the ability to make a
constrained extension conform to a new protocol (i.e., an array of
Equatable elements is Equatable), and so on. Swift 3.0 should provide those
generics features needed by the standard library, because they affect the
standard library's ABI.
> This message expands upon the notion of “completing generics”. It is not
a plan for Swift 3, nor an official core team communication, but it
collects the results of numerous discussions among the core team and Swift
developers, both of the compiler and the standard library. I hope to
achieve several things:
>
> Communicate a vision for Swift generics, building on the original
generics design document<
https://github.com/apple/swift/blob/master/docs/Generics.rst>, so we have
something concrete and comprehensive to discuss.
> Establish some terminology that the Swift developers have been using for
these features, so our discussions can be more productive (“oh, you’re
proposing what we refer to as ‘conditional conformances’; go look over at
this thread”).
> Engage more of the community in discussions of specific generics
features, so we can coalesce around designs for public review. And maybe
even get some of them implemented.
>
> A message like this can easily turn into a centithread<
http://www.urbandictionary.com/define.php?term=centithread>. To separate
concerns in our discussion, I ask that replies to this specific thread be
limited to discussions of the vision as a whole: how the pieces fit
together, what pieces are missing, whether this is the right long-term
vision for Swift, and so on. For discussions of specific language features,
e.g., to work out the syntax and semantics of conditional conformances or
discuss the implementation in compiler or use in the standard library,
please start a new thread based on the feature names I’m using.
>
> This message covers a lot of ground; I’ve attempted a rough
categorization of the various features, and kept the descriptions brief to
limit the overall length. Most of these aren’t my ideas, and any syntax I’m
providing is simply a way to express these ideas in code and is subject to
change. Not all of these features will happen, either soon or ever, but
they are intended to be a fairly complete whole that should mesh together.
I’ve put a * next to features that I think are important in the nearer term
vs. being interesting “some day”. Mostly, the *’s reflect features that
will have a significant impact on the Swift standard library’s design and
implementation.
>
> Enough with the disclaimers; it’s time to talk features.
>
> Removing unnecessary restrictions
>
> There are a number of restrictions to the use of generics that fall out
of the implementation in the Swift compiler. Removal of these restrictions
is a matter of implementation only; one need not introduce new syntax or
semantics to realize them. I’m listing them for two reasons: first, it’s an
acknowledgment that these features are intended to exist in the model we
have today, and, second, we’d love help with the implementation of these
features.
>
>
> *Recursive protocol constraints
>
> Currently, an associated type cannot be required to conform to its
enclosing protocol (or any protocol that inherits that protocol). For
example, in the standard library SubSequence type of a Sequence should

Re: [swift-evolution] Swift 3.1 discussions, go?

[Xiaodi Wu via swift-evolution]

I'd like to echo Muse's point. Accelerate is no solution: it's not
available on Linux (and cross-platform numerics is very much essential for
the sciences--I assume engineering and finance as well); moreover, it
doesn't solve the issue of, as you point out, other kinds of math.

The appeal to me of Swift was that it promised a memory-safe-by-default
systems programming language, a compiled language with performance that can
be in the same ballpark as C. So while specialized libraries like BLAS can
speed up matrix algebra considerably, IMO, the same kinds of math that are
done in C or Go or Rust without calling BLAS should perform roughly
equivalently when ported to Swift. That it doesn't should be a bug, and the
workaround shouldn't have to be dropping down to or calling out to
libraries written in C or Fortran.

Recently, I discovered that a straightforward numerics algorithm that only
adds, divides, multiplies, and compares floating point values slowed down
five to ten *times* between preview 3 and preview 4. This was stunning--and
if performance ever was comparable to C before (I didn't check for this
particular function), I know for sure that it isn't anymore! Although I'm
confident that the underlying cause will be found, it does raise questions
as to the continued wisdom of writing even somewhat performance-sensitive
math in Swift.
On Mon, Aug 1, 2016 at 20:04 Saagar Jha via swift-evolution <
swift-evolution@swift.org> wrote:

> Well, it depends on what kind of Math you’re trying to do. The Accelerate
> framework is available if you need performance.
>
> Saagar Jha
>
>
>
> On Aug 1, 2016, at 18:01, Muse M via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Have always wonder why Maths in Swift is slower than C and Go, it should
> be address with priority if Swift is to be adopt for engineering, financial
> and science industry.
>
> On Tue, Aug 2, 2016 at 4:43 AM, Charlie Monroe via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> See
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025711.html
>>
>> From what I understand, the discussion should stay focused on the main
>> topics for Swift 4 that Chris highlighted in
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html
>>
>> I had several ideas in mind, but am postponing them for Swift 5, seeing
>> the schedule...
>>
>>
>> On Aug 1, 2016, at 8:48 PM, Anton Zhilin via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> It was stated that 27th of July was the last date for proposal
>> acceptance, 29th of July was the last day for implementation, and 1th of
>> August should be the starting day of Swift 3.1-related discussions.
>> Am I right? Should we begin?
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Ross O'Brien via swift-evolution]

Assignment has the lowest precedence. 'x = condition ? y : z' doesn't make
sense if assignment is resolved before the ternary; the compiler would
complain that perhaps you meant '==' instead of '='.

There was an idea ages ago for essentially a 'switch expression' which was
effectively ternary for cases; if we ever make that a reality, it should
probably have the same precedence as ternary. But otherwise it's probably
going to continue to be a group of one.

On Tue, Aug 2, 2016 at 10:29 AM, Anton Zhilin via swift-evolution <
swift-evolution@swift.org> wrote:

> 2016-08-02 7:18 GMT+03:00 Félix Cloutier :
>
>> I disagree. The binary operators have properties that are comparable to
>> arithmetic operators, and their precedence is easy to define as such. & has
>> multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has
>> addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has
>> subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their
>> precedences are set accordingly (& is multiplicative, | and ^ are additive).
>>
>> The same applies to && and ||. Bit shifts are exponentiative.
>>
>
> I believe that such way of thinking is non-intuitive. In C, bitwise
> operators are not intervened by any others, except for comparison operators
> (agreed, it was a mistake). We now have possibilities to do so in Swift,
> even better. I suggest to branch off right before AdditionPrecedence:
>
> RangeFormation < Addition < Multiplication
> RangeFormation < BitwiseOr < BitwiseAnd < LogicalShift
>
> Another concern is NilCoalescing, which can be though to be semantically
> similar to Ternary. And at the same time it looks like || and &&, which
> would bring it between LogicalConjunction and Comparison.
> Also, do Casting and RangeFormation stand where they should?
>
> Next, Ternary operator is unique. Noone would ever like to put operators
> in this precedence group, because it would be confusing. Why not simplify
> our model and say that ?: has lower precedence than all binary operators,
> including Assignment? Unary > binary > ternary, sounds good?
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Discussion] Breaking precedence

[Anton Zhilin via swift-evolution]

2016-08-02 7:18 GMT+03:00 Félix Cloutier :

> I disagree. The binary operators have properties that are comparable to
> arithmetic operators, and their precedence is easy to define as such. & has
> multiplication-like properties (0*0=0, 0*1=0, 1*0=0, 1*1=1); | has
> addition-like properties (0+0=0, 0+1=1, 1+0=1, 1+1=2); ^ has
> subtraction-like properties (0-0=0, 0-1=-1, 1-0=1, 1-1=0), and their
> precedences are set accordingly (& is multiplicative, | and ^ are additive).
>
> The same applies to && and ||. Bit shifts are exponentiative.
>

I believe that such way of thinking is non-intuitive. In C, bitwise
operators are not intervened by any others, except for comparison operators
(agreed, it was a mistake). We now have possibilities to do so in Swift,
even better. I suggest to branch off right before AdditionPrecedence:

RangeFormation < Addition < Multiplication
RangeFormation < BitwiseOr < BitwiseAnd < LogicalShift

Another concern is NilCoalescing, which can be though to be semantically
similar to Ternary. And at the same time it looks like || and &&, which
would bring it between LogicalConjunction and Comparison.
Also, do Casting and RangeFormation stand where they should?

Next, Ternary operator is unique. Noone would ever like to put operators in
this precedence group, because it would be confusing. Why not simplify our
model and say that ?: has lower precedence than all binary operators,
including Assignment? Unary > binary > ternary, sounds good?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

[Tino Heth via swift-evolution]

> I would love to have a great web archive for swift-evolution—something with a 
> really solid search function, good threading, and most of the other niceties 
> of forums. It'd even be nice to have an upvote feature. But these are all 
> things that you could do without taking swift-evolution off of email.
afair, the option of keeping a mail interface was mentioned in one of the first 
posts, so none of the positive aspects of email would be lost (it just wouldn't 
be possible to use the "bonus-features" that aren't available in the medium)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution