[swift-evolution] Pitch: Allow generic functions to fulfill non-generic protocol requirements

[Jordan Rose]

We just don’t allow any broader acceptance in this case—no superclasses, no optionals, and no generics. I think we just consider it a bug (SR-522 <https://bugs.swift.org/browse/SR-522>).

Jordan


> On May 24, 2017, at 13:32, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
> 
> So, I’m working on a type, and would like to make it conform to `ExpressibleByArrayLiteral`. The thing is, I don’t actually care what type `Element` is as long as it conforms to `FixedWidthInteger` and `UnsignedInteger`. I tried writing this:
>   public init <U: FixedWidthInteger & UnsignedInteger> (arrayLiteral elements: U...) { … }
> But Xcode says my type doesn’t conform to `ExpressibleByArrayLiteral` unless I add an init that takes a concrete type:
>   public init(arrayLiteral elements: UInt...) { … }
> 
> Does anyone else think the generic init should to be able to satisfy `ExpressibleByArrayLiteral` (especially since `UInt` meets the conformance requirements)? I suspect that the compiler is complaining because the generic init function implies that the `Element` associated type is a generic constraint, rather than a concrete type (which maybe makes this related to generic protocols?). I think that’s only an issue because of the current ExpressibleBy*Literal protocols’ reliance on associated types to specify the relevant init’s signature, though. If the protocols (or literal system) could be re-architected so they don't need those associated types, it might make implementing this easier. I don’t know how much work either approach would be. Nor am I sure if it’d be better for this to be a use-case for another proposal instead of its own thing.
> 
> - Dave Sweeris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170525/f17dc5f5/attachment.html>