[swift-evolution] generic associatedtype?
Vladimir.S
svabox at gmail.com
Tue Sep 20 09:34:55 CDT 2016
On 20.09.2016 16:43, Jens Persson via swift-evolution wrote:
> 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.
Very interesting. Could you share some examples of how your source code
looks like(this "code-generating Swift code") and what is produced by this
"meta-programming-tool" ?
>
> /Jens
>
>
> On Mon, Sep 19, 2016 at 10:07 PM, Goffredo Marocchi <panajev at gmail.com
> <mailto: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 <mailto: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 <mailto:devteam.codafi at gmail.com>> wrote:
>>
>>
>>> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution
>>> <swift-evolution at swift.org <mailto: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
>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/015089.html>
>>> )
>>>
>>> Thanks,
>>> /Jens
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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
>
More information about the swift-evolution
mailing list