> On Dec 23, 2016, at 12:32 PM, David Sweeris via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> (I feel like I’ve already written this... I looked through my sent mail and
> didn’t see anything, but my sincerest apologies if I started this thread a
> month ago and forgot about it or something.)
>
> I no longer recall exactly what first made me want to do this (probably
> something in my on-going “teach the compiler calculus” project), but I’ve
> been thinking lately that it could be quite handy to overload types
> themselves based on the value of generic parameters. As a somewhat contrived
> example:
> struct Array <T> { /*everything exactly as it is now*/ }
> struct Array <T> where T == Bool { /* packs every 8 bools into a UInt8 for
> more efficient storage */ }
>
> We can already do this with functions… Conceptually this isn’t any different.
Actually this is a major complication because of the runtime generics model.
Imagine you have a function that takes a T and constructs an Array<T>. Now it
has to do dynamic dispatch to find the right type metadata (is it the “generic”
Array<T>, or the specialized Array<Bool>?)
> As long as the specific version exposes everything the generic version does
> (easy for the compiler to enforce), I think everything would just work
> (famous last words).
What if another module defines an extension of Array<T>, but not ‘Array<T>
where T == Bool’?
> In this example, the subscript function would need to extract the specified
> bit and return it as a Bool instead of simply returning the specified
> element. The `Element` typealias would be `Bool` instead of `UInt8`, which
> would mean the size/stride might be different than expected (but that’s why
> we have `MemoryLayout<>`).
>
> Anyway, because generic structs & functions already can’t make assumptions
> about a generic argument (beyond any constraints, of course), I think this
> should be in phase 2… but I’m quite hazy on how generics work once the code’s
> been compiled, so maybe not.
Another way of modeling this might be to define a protocol, say
“RepresentableInArray”, which implements get and set methods that take a
pointer to a buffer, and an index. A default implementation in a protocol
extension would just load and store the value. ‘Bool’ would define its own
conformance which performs bitwise operations.
However I think this is out of scope for stage 2 — it doesn’t fix any obvious
major shortcoming in the language, it vastly complicates the implementation and
it’s not required to achieve our ABI stability goals.
Slava
>
> - Dave Sweeris
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
