Re: [swift-dev] [swift-evolution] Re-pitch: Deriving collections of enum cases

> On Nov 14, 2017, at 9:06 PM, Brent Royal-Gordon via swift-dev > wrote: > >> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu > > wrote: >> >> 1. It must be possible to easily access the count of values, and to access >> any particular value using contiguous `Int` indices.

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

wrote: >> >>> On Nov 2, 2017, at 5:20 PM, Jonathan Hull via swift-dev >>> mailto:swift-dev@swift.org>> wrote: >>> >>> It looks like we have a good solution. Per Steve and David’s suggestions: >>> >>> 1) Make FloatingPoint == re

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

It looks like we have a good solution. Per Steve and David’s suggestions: 1) Make FloatingPoint == reflexive 2) Add &== to FloatingPoint for those who specifically want IEEE behavior 3) Add a warning + fixit to ‘a != a’ We should take this to evolution... Thanks, Jon > On Nov 1, 2017, at 10

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 31, 2017, at 9:07 AM, Stephen Canon wrote: > > [Replying to the thread as a whole] > > There have been a bunch of suggestions for variants of `==` that either trap > on NaN or return `Bool?`. I think that these suggestions result from people > getting tunnel-vision on the idea of “ma

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 11:44 PM, Xiaodi Wu wrote: > > On Fri, Oct 27, 2017 at 1:30 AM, Jonathan Hull > wrote: > One completely different idea, which I brought up a year or so ago, is to do > what we do with pointers around this. That is you have your fast/unsafe IEEE >

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

One completely different idea, which I brought up a year or so ago, is to do what we do with pointers around this. That is you have your fast/unsafe IEEE Floats/Doubles/etc that have a scarier name. These do not conform to Equatable or Comparable, but have their own version of IEEE equality/co

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 8:16 PM, Xiaodi Wu wrote: > > On Thu, Oct 26, 2017 at 4:34 PM, Jonathan Hull > wrote: > >> On Oct 26, 2017, at 11:47 AM, Xiaodi Wu > > wrote: >> >> On Thu, Oct 26, 2017 at 1:30 PM, Jonathan Hull >

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 11:47 AM, Xiaodi Wu wrote: > > On Thu, Oct 26, 2017 at 1:30 PM, Jonathan Hull > wrote: > Now you are just being rude. We all want Swift to be awesome… let’s try to > keep things civil. > > Sorry if my reply came across that way! That wasn't at all

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

Now you are just being rude. We all want Swift to be awesome… let’s try to keep things civil. You said it was impossible, so I gave you a very quick example showing that the current behavior was still possible. I wasn’t recommending that everyone should only ever use that example for all thing

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 9:40 AM, Xiaodi Wu wrote: > > On Thu, Oct 26, 2017 at 11:38 AM, Jonathan Hull > wrote: > >> On Oct 26, 2017, at 9:34 AM, Xiaodi Wu > > wrote: >> >> On Thu, Oct 26, 2017 at 10:57 AM, Jonathan Hull >

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 9:34 AM, Xiaodi Wu wrote: > > On Thu, Oct 26, 2017 at 10:57 AM, Jonathan Hull > wrote: > >> On Oct 26, 2017, at 8:19 AM, Xiaodi Wu > > wrote: >> >> >> On Thu, Oct 26, 2017 at 07:52 Jonathan Hull >

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 26, 2017, at 8:19 AM, Xiaodi Wu wrote: > > > On Thu, Oct 26, 2017 at 07:52 Jonathan Hull > wrote: >> On Oct 25, 2017, at 11:22 PM, Xiaodi Wu > > wrote: >> >> On Wed, Oct 25, 2017 at 11:46 PM, Jonathan Hull > >

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 25, 2017, at 11:22 PM, Xiaodi Wu wrote: > > On Wed, Oct 25, 2017 at 11:46 PM, Jonathan Hull > wrote: > As someone mentioned earlier, we are trying to square a circle here. We can’t > have everything at once… we will have to prioritize. I feel like the > preced

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

As someone mentioned earlier, we are trying to square a circle here. We can’t have everything at once… we will have to prioritize. I feel like the precedent in Swift is to prioritize safety/correctness with an option ignore safety and regain speed. I think the 3 point solution I proposed is a

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 25, 2017, at 9:01 AM, David Sweeris via swift-dev > wrote: > > That said, I fully acknowledge that this is all above my pay grade (also I > hadn't realized that the issue was as settled as it apparently is). If > splitting the protocols is a no-go from the get go, I'll go back to tryi

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

One possibility which might be easier would be to just depreciate Float’s Equatable conformance and provide a warning/fixit (suggesting how to use the new ‘~’ relation). > On Oct 25, 2017, at 2:35 AM, Jonathan Hull wrote: > > There is something interesting here. I like that ‘Bool?’ really rep

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

There is something interesting here. I like that ‘Bool?’ really represents what we need from the relation on Float. I think it solves the objection that Xiaodi mentioned with a PartialEq protocol. If everyone just switches to using PartialEq in generic contexts because they want it to work wi

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 21, 2017, at 6:27 PM, Xiaodi Wu wrote: > > On Sat, Oct 21, 2017 at 7:52 PM, Jonathan Hull > wrote: > >> On Oct 21, 2017, at 3:02 PM, Xiaodi Wu > > wrote: >> >> On Fri, Oct 20, 2017 at 2:42 PM, Stephen Canon >

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 21, 2017, at 3:02 PM, Xiaodi Wu wrote: > > On Fri, Oct 20, 2017 at 2:42 PM, Stephen Canon > wrote: >> On Oct 20, 2017, at 8:21 AM, David Zarzycki via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >>> On Oct 20, 2017, at 07:51, Xiaodi Wu via swift-dev >>

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

I can support that. > On Oct 20, 2017, at 10:21 AM, Xiaodi Wu wrote: > > > On Fri, Oct 20, 2017 at 10:10 Matthew Johnson > wrote: >> On Oct 20, 2017, at 9:36 AM, Xiaodi Wu via swift-dev > > wrote: >> >> >> On Fri, Oct 20, 2017 at 07:

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

> On Oct 20, 2017, at 7:36 AM, Xiaodi Wu wrote: > > > On Fri, Oct 20, 2017 at 07:21 David Zarzycki > wrote: > > >> On Oct 20, 2017, at 07:51, Xiaodi Wu via swift-dev > > wrote: >> >> On Fri, Oct 20, 2017 at 1:22 AM, Jonathan Hull >

Re: [swift-dev] Rationalizing FloatingPoint conformance to Equatable

+1 for trapping unless using &==. In the case of ‘Float?’ we could also map to nil. This is probably a more appropriate discussion for evolution though... > On Oct 19, 2017, at 9:48 PM, Brent Royal-Gordon via swift-dev > wrote: > >> On Oct 19, 2017, at 4:29 PM, Xiaodi Wu via swift-dev >

Re: [swift-dev] Reconsidering the global uniqueness of type metadata and protocol conformance instances

Is there a way to split the difference? You would still have a repository of canonical metadata, but you could have another non-unique structure which can be used for most cases without having to go get the canonical version. You could use the non-unique structure to lookup the canonical versi

Re: [swift-dev] New conformances and source compatibility

I think a stop-gap solution is ok in the short term. Longer term, it would be nice to have: 1) A way to mark a conformance as weak. That is, it is only used if a non-weak conformance is unavailable. 2) A way to explicitly declare that a method/property satisfies a protocol’s method/property eve