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

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

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

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

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

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

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

> 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 > >

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

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: >

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

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

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

> 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

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

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

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

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

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

> 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

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

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,

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

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

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

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",

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

+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

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

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

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

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

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

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

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

> 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

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

> 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

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

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

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

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

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

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"

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

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

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

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?

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

> 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

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

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

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

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,

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

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

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

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

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

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, >

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

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

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

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

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

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,

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

> 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

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

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

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

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

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

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

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

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 >

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

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

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

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

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

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 >>

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

@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

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

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

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

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

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

> 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

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

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

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

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

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

> 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

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

> 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

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

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. :)

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

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 >

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

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

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

> 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

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

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",

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

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

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

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

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

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

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

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. >

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

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

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

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

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

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

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

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 < >

Re: [swift-evolution] [META] Gmane and 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

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

> 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

Re: [swift-evolution] [META] Gmane and 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]

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

> 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 >>>

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

> 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

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

> 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

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

+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,

[swift-evolution] [Manifesto] Completing Generics

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

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

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

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

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

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

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 >

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

> 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