On Tue, Dec 29, 2015, at 02:11 PM, Joe Groff wrote: > >> On Dec 29, 2015, at 1:24 PM, Matthew Johnson via swift-evolution <swift- >> evolut...@swift.org> wrote: >> >> Hi Kevin, >> >> Thanks for taking time to look at the proposal. >> >> The technique you show here is not bad, but it has several >> deficiencies IMO which are addressed by the solution in the proposal. >> >> 1. Forwarding should be an implementation detail, not exposed as it >> is with this method. > > This could theoretically be managed by access control on protocol > conformances: > >> public struct Foo: internal SequenceTypeForwarder, public >> SequenceType { ... } > > though that's even more boilerplatey, and makes it easy to > accidentally expose more API than you intended to.
That's an interesting approach. Another workaround for this today is to use an operator (similar to how the stdlib uses ~> internally for a lot of stuff) coupled with a phantom type. As an example (using ~> because why not): // phantom type struct _SequenceTypeForwarder {} protocol SequenceTypeForwarder : SequenceType { typealias ForwardedSequenceType : SequenceType func ~>(this: Self, _: _SequenceTypeForwarder) -> ForwardedSequenceType } The need for the phantom type is a bit unfortunate (you can't just use SequenceTypeForwarder.Protocol because it complains about the Self or associated type requirements issue). -Kevin Ballard
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution