<div dir="ltr">You don't necessarily need variadic generics to enable tuples to be nominal types. Though you do need some changes to the generic type system. One possibility is:<div><br></div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">struct Tuple_0_Int_1_Int<T/*, T0, T1*/>: Collection /*where T0: T, T1: T*/ { // Mangle name. Need covariant generics to enable constraint of T0 and T1.<br> typealias Element = T<br> typealias Index = Int<br> typealias SubSequence = Slice<Tuple_0_Int_1_Int<T/*, T0, T1*/>><br> var _0_: T/*0*/ // Unique name.<br> var _1_: T/*1*/ // Unique name.<br> let startIndex: Int = 0<br> let endIndex: Int = 2<br> subscript(position: Int) -> T {<br> switch position {<br> case 0: return _0_<br> case 1: return _1_<br> default: fatalError("Index out of bounds (must be 0 or 1).")<br> }<br> }<br> func index(after i: Int) -> Int {<br> return i + 1<br> }<br>}<br><br>// Ideally:<br>// 1. Extension on Tuple_0_Int_1_Int (SE-143).<br>// 2. Collection extension rather than on every Tuple (SE-143 extension).<br>func == <T>(lhs: Tuple_0_Int_1_Int<T>, rhs: Tuple_0_Int_1_Int<T>) -> Bool where T: Equatable {<br> let size = lhs.count<br> guard size == rhs.count else {<br> return false<br> }<br> for i in 0 ..< size {<br> guard lhs[i] == rhs[i] else {<br> return false<br> }<br> }<br> return true<br>}<br></blockquote><br><div>The above is valid Swift 4, but I really want to be able to say:</div><div><ol><li>`struct Tuple_0_Int_1_Int<T, T0, T1>: Collection where T0: T, T1: T`, i.e. covariant generics.<br></li><li>Ideally SE143+ also, so that I can extend Collection to implement Equatable, Hashable, etc.</li></ol><div>Note:</div></div><div><ol><li>Tuples extend Collection, not MutableCollection.</li><li>T is the base type of T0 and T1.</li><li>A Collection of T is sufficient to write interesting generic algorithms; equals, etc.</li></ol></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"> -- Howard.<br></div></div>
<br><div class="gmail_quote">On 23 November 2017 at 11:50, David Sweeris via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><br><div>On Nov 21, 2017, at 22:54, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div><blockquote type="cite"><div>On Nov 21, 2017, at 10:48 PM, David Hart <<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>> wrote:</div><br class="m_7566537071766444284Apple-interchange-newline"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br class="m_7566537071766444284Apple-interchange-newline"><br>On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div><br><div><br><blockquote type="cite"><div>On Nov 21, 2017, at 10:37 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" target="_blank">clattner@nondot.org</a>> wrote:</div><br class="m_7566537071766444284Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space">On Nov 21, 2017, at 9:25 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</a>> wrote:<br><div><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div><blockquote type="cite"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Or alternatively, one could decide to make the generics system *only and forever* work on nominal types, and make the syntactic sugar just be sugar for named types like Swift.Tuple, Function, and Optional. Either design could work.</div></div></blockquote><br></div><div>We don’t have a way to make it work for function types, though, because of parameter-passing conventions. Well, assuming we don’t invent something that allows:</div><div><br></div><div><span class="m_7566537071766444284Apple-tab-span" style="white-space:pre-wrap"> </span>Function<Double, inout String></div><div><br></div><div>to exist in the type system. Tuple labels have a similar problem.</div></div></div></blockquote><br></div><div>I’m totally aware of that and mentioned it upthread.<span class="m_7566537071766444284Apple-converted-space"> </span></div></div></div></blockquote><div><br></div><div>Eh, sorry I missed it.</div><br><blockquote type="cite"><div><div style="word-wrap:break-word;line-break:after-white-space"><div> There are various encoding tricks that could make this work depending on how you want to stretch the current generics system…</div></div></div></blockquote><br></div><div>I think it’s straightforward and less ugly to make structural types allow extensions and protocol conformances.</div></div></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Can somebody explain to me what is less ugly about that? I would have naturally thought that the language would be simpler as a whole if there only existed nominal types and all structural types were just sugar over them.</div></div></blockquote></div><br><div>See Thorsten’s response with, e.g.,</div><div><br></div><div><span class="m_7566537071766444284Apple-tab-span" style="white-space:pre-wrap"> </span> Function<Double, InoutParam<String>, Param<Int>></div><div><br></div><div>which handles “inout” by adding wrappers around the parameter types (which one would have to cope with in any user of Function), but still doesn’t handle argument labels. To handle argument labels, we would need something like strings as generic arguments.</div></div></blockquote><div><br></div></span><div>Oh, good! A use case for “literals as generic parameters” <i>other</i> than Vectors and Fixed-Size Arrays!</div><div><br></div><div>- Dave Sweeris</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>