>> Deliberately missing your point, I’d say the problem is that Swift has two >> kinds of generics — one for class types and one for protocols. The concepts >> are fairly easy to grasp individually, but become horrendously complex when >> allowed to interact. Personally, I regard this as a bug in the language >> design. >> >> OTOH, C++ has historically proved that generics (i.e. templates) > > I really wish people would stop referring to C++ templates as generics. C++ > template arguments can be numbers, strings, types, or anything else, and the > compiler will sit there and dutifully compute whatever program you encode via > templates. > > Generics are strictly type parameterization. They are far simpler to > understand and implement. And Swift has some techniques to avoid some of the > problems that arise even in “normal” use of C++ templates, like associated > types (to keep generic type signatures simple) and a type inference algorithm > that doesn’t completely suck. >
I haven't yet understood why there are two different syntaxes for class/function generics, with the <X,Y,Z> syntax but protocols are unadorned but have associated types. Naively I would have expected both to look the same, with parameters in angle brackets, clearly there's a very good reason for it, I just don't have the kind of experience with doing it another way, ie very much experience with C++ templates and their entire drawer of sharp edges, to appreciate it. I think it's time to resurrect the Swift book and read the second 1/2 of it more slowly than I did the first time. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
