Hey folks!
Thanks for all the great feedback and discussion.
I really like Tony's suggestion of the opt-in ValueEnumerable protocol.
However, I think Kevin is right that it should be a simple array.
If we wanted to get fancy, we could implement a custom integer indexed
collection that indexed into
Googling ‘swift iterate over enum cases’ yields many results of various levels
of hackery.
Obviously it’s trivial to write a computed property that returns an enum’s
cases as an
array, but maintaining that is prone to error. If you add another case, you
need to make sure
you update the array pro
eyPath respectively to instantiate strings
from KeyPaths and KeyPaths from Strings?
https://github.com/apple/swift/blob/c5ff1f2cac8da6a14330f4b033b94c7c926d2126/stdlib/public/SDK/Foundation/NSObject.swift#L84
On Fri, Aug 25, 2017 at 11:43 AM Joe Groff wrote:
>
> > On Aug 23, 2017, at 11:18 PM,
Hey folks!
Recently I’ve been working on a small library which leverages the Swift 4
Codable protocol
and KeyPaths to provide a Swift-y interface to CoreData. (It maps back and
forth between
native, immutable Swift structs and NSManagedObjects). In doing so I found a
couple of
frustrating lim
You would have this guarantee with the fixed-size arrays currently being
discussed.
Perhaps this could be an amendment to that proposal - you could declare an
array with bounds for its size.
Fixed-size arrays would be a subset of those where the upper and lower bounds
are equal.
They could also
y when dealing with generics and protocols,
> but that's just me.
>
>
> Elviro
>
>
> Il giorno 08 ago 2017, alle ore 10:44, Logan Shire via swift-evolution <
> swift-evolution@swift.org> ha scritto:
>
> Thanks for the feedback!
>
> Félix, sorry about
o, so you would only be able to pass the instance
> to functions that don't have constraints on T.
>
> But all in all, with my current understanding of the issue, I think that
> I'm favorable to the idea.
>
> Félix
>
> Le 7 août 2017 à 19:35, David Sweeris via swift-e
One of my longstanding frustrations with generic types and protocols has been
how hard it is to work with them when their type is unspecified.
Often I find myself wishing that I could write a function that takes a generic
type or protocol as a parameter, but doesn’t care what its generic type is.
Given we now have precedent in the form of the derived Codable conformance
coming in Swift 4.0,
it begs the question why we don’t offer the same behavior for value types that
declare themselves to be Equatable
and have all Equatable properties. E.g.
struct A: Equatable {
let foo: String
let
