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