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
