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@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.cod...@gmail.com>
>> wrote:
>>
>>> On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution
>>> <swift-evolution@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@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
