Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 25, 2017, at 8:28 PM, Jonathan Hull via swift-evolution > wrote: > > >> On Apr 25, 2017, at 7:17 PM, Xiaodi Wu > > wrote: >> >> On Tue, Apr 25, 2017 at 8:38 PM, Jonathan Hull >

Re: [swift-evolution] [pitch] Comparison Reform

Alternatively, we could introduce a new type `PotentiallyUnknown` that’s kind of like `Optional` but has different equality semantics. We’d probably also need to introduce a `PartiallyEquatable` (probably the wrong word) protocol too though. I don’t think this is really that feasible. protocol

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 25, 2017, at 7:17 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 8:38 PM, Jonathan Hull > wrote: > >> On Apr 25, 2017, at 5:25 PM, Xiaodi Wu > > wrote: >> >> On Tue,

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 25, 2017 at 8:38 PM, Jonathan Hull wrote: > > On Apr 25, 2017, at 5:25 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 6:53 PM, Jonathan Hull wrote: > >> I just wanted to ask for more detail on why this is a non-starter (it >>

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 25, 2017, at 5:25 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 6:53 PM, Jonathan Hull > wrote: > I just wanted to ask for more detail on why this is a non-starter (it seems > like most of my ideas are dismissed as

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

> Apparently the proposal is not updated yet. `EncodingError` and > `DecodingError` enums were said to be added as part of the move to the > Standard Library. > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/036001.html > >

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

> > On 26 Apr 2017, at 9:11 AM, Riley Testut via swift-evolution > wrote: > > I’m sure this has already been discussed, but why are the methods throwing > NSErrors and not Enums? If I’m remembering correctly, the original reason for > this was because this was

Re: [swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

I’m sure this has already been discussed, but why are the methods throwing NSErrors and not Enums? If I’m remembering correctly, the original reason for this was because this was meant to be a part of Foundation. Now that this is in the Standard Library, however, it seems strange that we’re

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 25, 2017 at 6:53 PM, Jonathan Hull wrote: > I just wanted to ask for more detail on why this is a non-starter (it > seems like most of my ideas are dismissed as “non-starters”, but I am > rarely given a detailed reason why). > > Migration would be a renaming from

Re: [swift-evolution] [pitch] Comparison Reform

I just wanted to ask for more detail on why this is a non-starter (it seems like most of my ideas are dismissed as “non-starters”, but I am rarely given a detailed reason why). Migration would be a renaming from ‘Double' to ‘Double?’, but it wouldn’t be cosmetic. It would free us to use a

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 25, 2017, at 7:34 AM, Stephen Canon wrote: > > >> On Apr 24, 2017, at 10:06 PM, Jonathan Hull via swift-evolution >> wrote: >> >> As I am thinking about it more, this means that for == and < >> >> NaN == NaN >> -0 == +0 >> +Inf < NaN >>

[swift-evolution] [Accepted] SE-0167: Swift Encoders

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md The review of SE-0167 "SE-0167: Swift Encoders” ran from April 6...12, 2017. The proposal is accepted.

[swift-evolution] [Accepted] SE-0166: Swift Archival & Serialization

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md Hello Swift Community, The review of SE-0166 “Swift Archival &

Re: [swift-evolution] [Pitch] Sequence Cleanup

I do not feel `AnySequence` for these overloads being a problem TBH, at least conceptually. IIUC a subsequence is expected to be a view to a consecutive range of the sequence, and require no extra storage since it is just about index manipulation. On the other hand, filtering or mapping a

Re: [swift-evolution] Memoization for functions without parameters in enums

That’s true, I also discovered the case, where the enum has a reference type as an associated value, which is then modified by a function. Such a function would clearly not be pure either, so a pure function should not be able to capture from a different scope and should not be able to access

[swift-evolution] [Pitch] Sequence Cleanup

Hello, I was planning to wait pitching this after I have tested the implementation, but I’m getting anxious, that I’ll miss the 4.0 boat, so here goes. This is early draft. I would especially appreciate analysis of the impact on source compatibility and ABI stability.

Re: [swift-evolution] [Pitch] Build configuration tests

> On Apr 24, 2017, at 4:19 PM, Xiaodi Wu wrote: > > I'm glad you've resurrected this idea. I think it's worth thinking about, > certainly. At the moment, I do have some thoughts, some of which I may have > already had but have now forgotten. They're more notions than

Re: [swift-evolution] [Pitch] Build configuration tests

> On Apr 24, 2017, at 7:59 PM, Ben Rimmington wrote: > > >> On 24 Apr 2017, at 21:07, Erica Sadun wrote: >> >> I'm going to throw this back out into the SE arena to see if there's still >> interest in these. >> >> https://github.com/apple/swift-evolution/pull/369 >>

Re: [swift-evolution] [Review] SE-0173: Add `MutableCollection.swap(_:with:)

Excellently written proposal, sensible motivation. Only nit is that `with` is not required and is better off removed, IMO. Here's why: * "swap a and b" and "swap a with b" are equivalent statements * there's no reason to use one phrasing for the free function and another with this method; the

[swift-evolution] [Review] SE-0173: Add `MutableCollection.swap(_:with:)

Hello Swift community, The review of SE-0173 "Add MutableCollection.swap(_:with:)" begins now and runs through April 28, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0173-swap-indices.md

Re: [swift-evolution] [Accepted] SE-0172: One-sided Ranges

> On 25 Apr 2017, at 17:47, Douglas Gregor wrote: > >> >> On Apr 25, 2017, at 9:20 AM, Tony Allevato > > wrote: >> >> >> On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution >>

Re: [swift-evolution] Memoization for functions without parameters in enums

Well, first, let's address some misconceptions in Tierry's email: "Enums in swift are purely functional and therefore functions without parameters always return the same value in an enum"...is not true. A function without parameters can have any amount of side effects and can return a random

Re: [swift-evolution] [Pitch] Enum with generic cases

Okay I will resubmit after post Swift 4.0 scope is discussed. Thanks! Alvarado, Joshua > On Apr 25, 2017, at 11:08 AM, Douglas Gregor wrote: > > >> On Apr 24, 2017, at 12:57 PM, Joshua Alvarado >> wrote: >> >> When would be a good time to

Re: [swift-evolution] Memoization for functions without parameters in enums

Sent from my iPhone > On Apr 25, 2017, at 06:44, Tierry Hörmann via swift-evolution > wrote: > > Hi all > > I discovered that memoization is currently a pain to implement when using > functional programming. > E.g. when implementing a lazy linked list, one

Re: [swift-evolution] [Pitch] Enum with generic cases

> On Apr 24, 2017, at 12:57 PM, Joshua Alvarado > wrote: > > When would be a good time to resubmit this proposal for discussion? Sometime in the summer we’re going to start talking about the scope of Swift post-4.0. > Or can I still proceed with the review and it

Re: [swift-evolution] [Accepted] SE-0172: One-sided Ranges

> On Apr 25, 2017, at 9:20 AM, Tony Allevato wrote: > > > On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution > > wrote: > While it's good that this was accepted I still feel there could be some

Re: [swift-evolution] [Accepted] SE-0172: One-sided Ranges

> On 25 Apr 2017, at 17:20, Tony Allevato wrote: > > > On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution > > wrote: > While it's good that this was accepted I still feel there could be some more

Re: [swift-evolution] [Accepted] SE-0172: One-sided Ranges

On Tue, Apr 25, 2017 at 8:55 AM Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > While it's good that this was accepted I still feel there could be some > more discussion about whether the operators should be prefix/postfix or > instead involve a more explicit declaration of

Re: [swift-evolution] [Accepted] SE-0172: One-sided Ranges

While it's good that this was accepted I still feel there could be some more discussion about whether the operators should be prefix/postfix or instead involve a more explicit declaration of one-sidedness. I still would very much prefer that the operator declarations were binary and take Void

[swift-evolution] Memoization for functions without parameters in enums

Hi all I discovered that memoization is currently a pain to implement when using functional programming. E.g. when implementing a lazy linked list, one obviously uses an enum to represent the data. But there is also a wrapper struct needed with lazy variables (especially a lazy property tail),

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 24, 2017, at 10:06 PM, Jonathan Hull via swift-evolution > wrote: > > As I am thinking about it more, this means that for == and < > > NaN == NaN > -0 == +0 > +Inf < NaN > > Since this would break from IEEE, I think we should also consider taking the >

Re: [swift-evolution] [pitch] Comparison Reform

On Mon, Apr 24, 2017 at 11:44 PM, David Waite via swift-evolution < swift-evolution@swift.org> wrote: > I still think this is a naming conflict more than anything else. > > The first expectation is that equatable and comparable provides strict > equality and strict total ordering, and that those

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 25, 2017 at 3:12 AM, David Waite wrote: > > On Apr 24, 2017, at 11:52 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 12:45 AM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> +1 >> >> What I am arguing

Re: [swift-evolution] [pitch] Comparison Reform

On Tue, Apr 25, 2017 at 2:41 AM, David Waite wrote: > > On Apr 24, 2017, at 11:52 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > > The only other alternative I can think of is to include a notion of > unordered to our comparisons… > >

Re: [swift-evolution] Swift Source Compatibility Suite now available at ci.swift.org

Does the Swift 3.0 compatibility mode refer to 3.0.1 or just 3.0? The lack of dynamic bridging of NSNumber and NSValue in 3.0 might cause some Darwin projects to pass compilation but fail in tests. Regards, Anders > On 25 Apr 2017, at 5:55 AM, Nicole Jacque via swift-evolution >

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 24, 2017, at 11:52 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 12:45 AM, Jonathan Hull via swift-evolution > > wrote: > +1 > > What I am arguing for is #2. We have two different expectations and

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 24, 2017, at 11:52 PM, Jonathan Hull via swift-evolution > wrote: > > The only other alternative I can think of is to include a notion of unordered > to our comparisons… > > What if we made <=> return an optional comparison result, with nil meaning >

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 24, 2017, at 10:54 PM, Xiaodi Wu wrote: > > On Tue, Apr 25, 2017 at 12:52 AM, Jonathan Hull > wrote: > The only other alternative I can think of is to include a notion of unordered > to our comparisons… > > What if we