Ok I feel like I’m ready to submit this `base` proposal for `Any<>` which can be extended even further later on.
Please take a last look: https://github.com/DevAndArtist/swift-evolution/blob/master/proposals/nnnn-mechanism-to-combine-types-and-protocols.md -- Adrian Zubarev Sent with Airmail Am 17. Mai 2016 bei 20:18:55, Adrian Zubarev (adrian.zuba...@devandartist.com) schrieb: I really would like to understand what you was trying to tell me. :) My English is a little rusty to understand every piece of someone's thought. By any chance someone could propose your ideas as an enhancement/upgrade of my `Any<>` mechanism later on? I mean like Joe did with removing `.self` which implies the ability of parsing expressions after 'as' and 'is' instead of just types. I’d update my document soon at let you guys have a quick look over it before I’ll submit a pull request. :) -- Adrian Zubarev Sent with Airmail Am 17. Mai 2016 bei 20:02:35, Douglas Gregor (dgre...@apple.com) schrieb: On May 17, 2016, at 10:40 AM, Adrian Zubarev <adrian.zuba...@devandartist.com> wrote: You don’t seem to be tackling the case of “A Collection whose Element type is String”. If we’re generalizing the current “protocol<>” notion, why not make it as powerful as a generic signature, with the ability to specify same-type constraints and conformances on associated types? - Doug Which part of the manifesto did I left out? ^^ Could you provide a quick pseudo code example? Do you mean something like `Any<Collection where Element == String>`? I’m not sure where I should consider such a scenario, maybe at future directions? That’s the part I’m referring to, yes. I just realized that your proposal isn’t lifting the restrictions on protocols with Self types or associated types, so my suggestion doesn’t make sense for your proposal without a significant increase in scope. - Doug
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
