Lovely!
There are some things that are... unideal.
Indeed. I hope they can be mitigated once we have a solid foundation in place (scoped conformances would support some useful mitigation strategies, BTW).
I was thinking that forcing specialization conformance was a "problem" to be solved, but actually, I think it's a feature. It forces people to write more expressive APIs.
If I understand you correctly, I agree. If we buy the idea that Swift's generic programming model is a good thing™, and derives some of that goodness™ from generic constraints and explicit conformance declarations, I have no problem saying they may be needed in order to use dependently-typed C++ templates from Swift generics.
If we can all agree that this is the correct path forward, we can start discussing more of the implementation details. Such as how we should represent concretizations and specializations in this model, and how much we want to lean on automatically generated protocols (we might need something like this for inheritance anyway).
I'm ready!
FWIW, I don't think we can expect the compiler to generate the right protocols automatically in all cases, and I'm not sure I know how to do even a decent job, so I'd prefer to start by building code generation helper tools (like some of Xcode's refactoring functionality) that spit out something the programmer can use as a starting point. I also view exploring in that area as a completely separable, relatively low-priority task.
I'm not sure what you have in mind regarding inheritance, though.
Let's leave non-type generic parameters for another discussion
(I know I brought them up, but I'm not sure I have the mental capacity to handle both this and the other discussion points in this thread).
Yes please, sir!
No, I'm saying that… but I actually don't think that it gives us anyting anymore. And it adds a lot of complexity/weirdness.
I'm afraid I still don't understand, but it sounds like you're saying it's not worth pursuing. If you change your mind, LMK and we can try again.