Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-04 Thread Ben Rimmington via swift-evolution
> On 4 Oct 2016, at 19:16, Joe Groff wrote: > >> On Oct 4, 2016, at 11:07 AM, Adrian Zubarev >> wrote: >> >> Doesn’t this imply more performance cost? Don’t get me wrong but the value >> here is not fixed and computed all over again which might waste

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-04 Thread Adrian Zubarev via swift-evolution
Okay thanks, I’ll keep that in mind. --  Adrian Zubarev Sent with Airmail Am 4. Oktober 2016 um 20:16:12, Joe Groff (jgr...@apple.com) schrieb: On Oct 4, 2016, at 11:07 AM, Adrian Zubarev wrote: Doesn’t this imply more performance cost? Don’t get me wrong

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-04 Thread Joe Groff via swift-evolution
> On Oct 4, 2016, at 11:07 AM, Adrian Zubarev > wrote: > > Doesn’t this imply more performance cost? Don’t get me wrong but the value > here is not fixed and computed all over again which might waste resources if > the calculation is complicated. Sure we

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-04 Thread Adrian Zubarev via swift-evolution
Doesn’t this imply more performance cost? Don’t get me wrong but the value here is not fixed and computed all over again which might waste resources if the calculation is complicated. Sure we could build some workarounds here and there, but the codebase won’t get any prettier after that.

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-04 Thread Joe Groff via swift-evolution
> On Oct 3, 2016, at 12:50 PM, Adrian Zubarev via swift-evolution > wrote: > > Hi there, > > I’m interested if this idea has some potential future in Swift or not. > > Currently RawRepresentable enums accept only a subset of literal types like > String, Character

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-04 Thread Karl Wagner via swift-evolution
Also IIRC, both of these limitations go away if you conform to RawRepresentable yourself. There is no magic to RawRep. The compiler will just synthesise a failable initialiser and 'rawValue' computed property accessor. Both just simple switch statements matching your provided

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-04 Thread Karl Wagner via swift-evolution
Enum raw types don't have to be strings/integers, but they have to be expressable by string or integer literals. We don't guarantee uniqueness per se, but we do check for duplicate literals and auto-increment integers to fill gaps. So all you have to do is make

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-04 Thread Xiaodi Wu via swift-evolution
On Tue, Oct 4, 2016 at 2:07 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > There are still a lot of open questions here to solve. > >- How to statically guarantee the uniqueness + immutability of the >hashValues? > - > > Should we allow only the

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-04 Thread Adrian Zubarev via swift-evolution
There are still a lot of open questions here to solve. How to statically guarantee the uniqueness + immutability of the hashValues? Should we allow only the usage of an initializer? Sometimes an init might be not enough and you’d wish you can use custom function which would return the same

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-04 Thread Rien via swift-evolution
+1. I have several cases where I cannot use enums, this proposal would solve that. > On 03 Oct 2016, at 21:53, Adrian Zubarev via swift-evolution > wrote: > > I made a typo in my previous post. > > Bikeshdding with correct types: > > struct A : Hashable { /*

Re: [swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-03 Thread Adrian Zubarev via swift-evolution
I made a typo in my previous post. Bikeshdding with correct types: struct A : Hashable { /* implement everything */ } // Variant 1: enum Test : A { case something = A(value: "something") case nothing = A(value: "nothing") } // Variant 2: protocol SomeFancyName : RawRepresentable { … }

[swift-evolution] [Pitch] Hashable types on RawRepresentable enums or a protocol for custom enum-like types

2016-10-03 Thread Adrian Zubarev via swift-evolution
Hi there, I’m interested if this idea has some potential future in Swift or not. Currently RawRepresentable enums accept only a subset of literal types like String, Character and the Integer family (enum Name : String { … }). Sometimes this is not enough for my use-case and I wish I could feed