> 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
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
> 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
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.
> 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
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
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
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
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
+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 { /*
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 { … }
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
12 matches
Mail list logo