<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;">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.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">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.</div><div style="direction: inherit;"><br></div>Sent from my iPhone</div><div><br>On 19 Sep 2016, at 14:14, Jens Persson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">Ok, thanks! I take it that we should not expect any dramatic advances of Swift's type system any time soon.<div><br><div>Reason for asking is that we are trying to write an API for N-dimensional graphics/audio/signal/data processing.</div><div><br></div><div>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.<div><br></div><div>This has turned out to be impossibly hard to write in current Swift, unless you are willing to either<br></div><div><br></div><div>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.</div><div><br></div><div>2. Forget about code reuse / abstractions.</div><div><br></div><div>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.</div><div><br></div><div>So we'll probably go with option 2 and spell out / generate code for each and every permutation of</div><div>(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</div><div><br></div><div>A generic StaticVector type with type parameters for its Count and Element.</div><div><br></div><div>A generic N-dimensional array type with type parameters for its</div><div>(NDim)Index: StaticVector (where Index.Element == Int)</div><div>and</div><div>Element</div><div><br></div><div>Or we'll have to use (Obj) C++ : /</div><div><br></div><div>/Jens</div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 19, 2016 at 3:22 AM, Robert Widmann <span dir="ltr"><<a href="mailto:devteam.codafi@gmail.com" target="_blank">devteam.codafi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div><div class="h5"><blockquote type="cite"><div>On Sep 17, 2016, at 6:37 PM, Jens Persson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">Has there been any discussions about the possibility of having generic associatedtypes?<div><br></div><div>I (naively) think that it would open up a lot of possibilities.</div><div>Because if, for example, we could do this:</div><div><br></div><div>protocol CountType {</div><div> associatedtype Storage<E></div><div> ...</div><div>}</div><div><br></div><div>Then we could do this:</div><div><br></div><div>struct Count1 : CountType {</div><div> typealias Storage<E> = (E)</div><div> ...</div><div>}</div><div>struct Count2 : CountType {</div><div> typealias Storage<E> = (E, E)</div><div> ...</div><div>}</div><div>struct Count3 : CountType {</div><div> typealias Storage<E> = (E, E, E)</div><div> ...</div><div>}</div><div>...</div><div>protocol StaticArrayType {</div><div> associatedtype Count: CountType</div><div> associatedtype Element</div><div> ...</div><div>}</div><div>struct StaticArray<C: CountType, Element> : StaticArrayType {</div><div> typealias Count = C</div><div> var storage: C.Storage<Element></div><div> ...</div><div>}</div><div><br></div><div><br></div><div><br></div><div><div>Would adding support for generic associatedtypes be possible? Are there any plans for it?</div></div></div></div></blockquote><div><br></div></div></div><div><div>Possible, yes, plans, no.</div><div><br></div><div>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?</div><div><br></div><div>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-<wbr>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.</div><div><br></div><div>tl;dr Basic examples like the ones you cite hide the kinds of tremendously <strike>evil</strike> fun things you can do once you have these kinds of features. </div></div><br><blockquote type="cite"><div><span class=""><div dir="ltr"><div><br></div><div>(</div><div>I tried searching for it but I found only this:</div><div><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/015089.html" target="_blank">https://lists.swift.org/<wbr>pipermail/swift-evolution/<wbr>Week-of-Mon-20160411/015089.<wbr>html</a><br></div><div>)</div><div><br></div><div>Thanks,</div><div>/Jens</div><div><br></div></div></span>
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>