[swift-evolution] generic associatedtype?

[Jens Persson]

Sure, but the reason to go for C++ in this case would only be to be able to
use eg its templates and constexprs, things that doesn't translate well
into Swift. And I think it's a long term goal of Swift to become a systems
language.

We ended up making a meta-programming-tool that we use as a Build Phase,
before compilation, that lets us write code-generating Swift code, within
our ordinary Swift code. (A bit like GYB but Swift-only, using just regular
Swift within our regular Swift source files.)

This DIY meta programming facility let's us overcome the current
limitations of Swift's type system in a somewhat convenient/nice way.

/Jens


On Mon, Sep 19, 2016 at 10:07 PM, Goffredo Marocchi <panajev at gmail.com>
wrote:

> If you have to compromise that much, it makes for a very compelling case
> to go for C++ wrapped in Objective-C(++) as far as that section of the code
> is concerned and call it from Swift using the already provided bridging
> support.
>
> I do not think anyone will question the purity of our bodily fluids/minds
> if we do not write 100% of code in Swift :), support for interoperability
> with other languages is there for a reason IMHO and should be expanded and
> not begrudged.
>
> Sent from my iPhone
>
> On 19 Sep 2016, at 14:14, Jens Persson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Ok, thanks! I take it that we should not expect any dramatic advances of
> Swift's type system any time soon.
>
> Reason for asking is that we are trying to write an API for N-dimensional
> graphics/audio/signal/data processing.
>
> Metal, vDSP, simd, etc. would perhaps be used, but only behind the scenes,
> eventually, as necessary, since we want something more uniform and
> math-like, thus allowing for a more rapid experimental style of coding,
> where you can quickly try something out for a different number of
> dimensions, etc.
>
> This has turned out to be impossibly hard to write in current Swift,
> unless you are willing to either
>
> 1. Forget about performance and type safety, ie use a standard Array
> (instead of a static vector with type-level Count as well as Element) for
> N-dimensional positions, matrices, vectors, indices, etc.
>
> 2. Forget about code reuse / abstractions.
>
> Option 1 is not an alternative. We want to let the compiler (and our code)
> know/optimize as much as possible, otherwise it will be unusably slow even
> for ("rapid") prototyping.
>
> So we'll probably go with option 2 and spell out / generate code for each
> and every permutation of
> (dim, data-structure, function/algorithm), and sadly this will also be
> necessary for every piece of code that uses the API, since it is impossible
> to write eg
>
> A generic StaticVector type with type parameters for its Count and Element.
>
> A generic N-dimensional array type with type parameters for its
> (NDim)Index: StaticVector (where Index.Element == Int)
> and
> Element
>
> Or we'll have to use (Obj) C++ : /
>
> /Jens
>
>
>
> On Mon, Sep 19, 2016 at 3:22 AM, Robert Widmann <devteam.codafi at gmail.com>
> wrote:
>
>>
>> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> Has there been any discussions about the possibility of having generic
>> associatedtypes?
>>
>> I (naively) think that it would open up a lot of possibilities.
>> Because if, for example, we could do this:
>>
>> protocol CountType {
>>     associatedtype Storage<E>
>>     ...
>> }
>>
>> Then we could do this:
>>
>> struct Count1 : CountType {
>>     typealias Storage<E> = (E)
>>     ...
>> }
>> struct Count2 : CountType {
>>     typealias Storage<E> = (E, E)
>>     ...
>> }
>> struct Count3 : CountType {
>>     typealias Storage<E> = (E, E, E)
>>     ...
>> }
>> ...
>> protocol StaticArrayType {
>>     associatedtype Count: CountType
>>     associatedtype Element
>>     ...
>> }
>> struct StaticArray<C: CountType, Element> : StaticArrayType {
>>     typealias Count = C
>>     var storage: C.Storage<Element>
>>     ...
>> }
>>
>>
>>
>> Would adding support for generic associatedtypes be possible? Are there
>> any plans for it?
>>
>>
>> Possible, yes, plans, no.
>>
>> Generic associated types go part and parcel with higher-kinded
>> quantification and higher-kinded types, the implementation challenges of
>> which have been discussed thoroughly on this list and elsewhere.  Is there
>> a particular flavor you had in mind?
>>
>> One major problem is that presumably you’d want to constrain such a
>> generic associatedtype and then we’d have to have some kind of
>> type-level-yet-runtime-relevant apply of a generic witness table to
>> another potentially generic witness.  It’s not clear what that kind of
>> thing would look like, or how far it would have to be taken to get the kind
>> of support you would expect from a basic implementation higher
>> associatedtypes.  Implementations in languages like Haskell tend to also be
>> horrendously inefficient - I believe Edward Kmett calls is the “Mother May
>> I” effect of forcing a witness table to indirect through multiple layers of
>> the witness because inlining necessarily fails for the majority of these
>> things in the MTL.
>>
>> tl;dr Basic examples like the ones you cite hide the kinds of
>> tremendously evil fun things you can do once you have these kinds of
>> features.
>>
>>
>> (
>> I tried searching for it but I found only this:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-
>> Mon-20160411/015089.html
>> )
>>
>> Thanks,
>> /Jens
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160920/65e9f687/attachment.html>