<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">We just don’t allow <i class="">any</i> broader acceptance in this case—no superclasses, no optionals, and no generics. I think we just consider it a bug (<a href="https://bugs.swift.org/browse/SR-522" class="">SR-522</a>).</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On May 24, 2017, at 13:32, David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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:<div class=""><div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">public</span><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">init</span><span style="font-variant-ligatures: no-common-ligatures" class=""> <U: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">FixedWidthInteger</span><span style="font-variant-ligatures: no-common-ligatures" class=""> & </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">UnsignedInteger</span><span style="font-variant-ligatures: no-common-ligatures" class="">> (arrayLiteral elements: </span><span style="font-variant-ligatures: no-common-ligatures; color: #4f8187" class="">U</span><span style="font-variant-ligatures: no-common-ligatures" class="">...) { </span>… }</div></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class="">But Xcode says my type doesn’t conform to `ExpressibleByArrayLiteral` unless I add an init that takes a concrete type:</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><div style="margin: 0px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">public</span><span style="font-variant-ligatures: no-common-ligatures" class=""> </span><span style="font-variant-ligatures: no-common-ligatures; color: #ba2da2" class="">init</span><span style="font-variant-ligatures: no-common-ligatures" class="">(arrayLiteral elements: </span><span style="font-variant-ligatures: no-common-ligatures; color: #703daa" class="">UInt</span><span style="font-variant-ligatures: no-common-ligatures" class="">...) {</span><font face="Menlo" class=""> </font><font face="Menlo" class="">…</font> }</div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class="">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.</span></div><div class=""><span style="font-variant-ligatures: no-common-ligatures" class=""><br class=""></span></div><div class="">- Dave Sweeris</div></span></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>