<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 23, 2016, at 12:32 PM, 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="">(I feel like I’ve already written this... I looked through my sent mail and didn’t see anything, but my sincerest apologies if I started this thread a month ago and forgot about it or something.)<div class=""><br class=""></div><div class="">I no longer recall exactly what first made me want to do this (probably something in my on-going “teach the compiler calculus” project), but I’ve been thinking lately that it could be quite handy to overload types themselves based on the value of generic parameters. As a somewhat contrived example:</div><div class=""><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">struct</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> Array <T> { </span><span style="font-variant-ligatures: no-common-ligatures" class="">/*everything exactly as it is now*/</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> }</span></div></div><div class=""><div style="margin: 0px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">struct</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> Array <T> </span><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">where</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> T == <span style="color: rgb(112, 61, 170);" class="">Bool</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> { </span><span style="color: rgb(0, 132, 0); font-variant-ligatures: no-common-ligatures;" class="">/* packs every 8 bools into a UInt8 for more efficient storage */</span><span style="font-variant-ligatures: no-common-ligatures;" class=""> }</span></span></div></div></blockquote><div class=""><span style="font-variant-ligatures: no-common-ligatures;" class=""><br class=""></span></div><div class="">We can already do this with functions… Conceptually this isn’t any different.</div></div></div></div></blockquote><div><br class=""></div><div>Actually this is a major complication because of the runtime generics model. Imagine you have a function that takes a T and constructs an Array<T>. Now it has to do dynamic dispatch to find the right type metadata (is it the “generic” Array<T>, or the specialized Array<Bool>?)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""> As long as the specific version exposes everything the generic version does (easy for the compiler to enforce), I <i class="">think</i> everything would just work (famous last words).</div></div></div></div></blockquote><div><br class=""></div>What if another module defines an extension of Array<T>, but not ‘Array<T> where T == Bool’?</div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class=""> In this example, the subscript function would need to extract the specified bit and return it as a Bool instead of simply returning the specified element. The `Element` typealias would be `Bool` instead of `UInt8`, which would mean the size/stride might be different than expected (but that’s why we have `MemoryLayout<>`).</div><div class=""><br class=""></div><div class="">Anyway, because generic structs & functions already can’t make assumptions about a generic argument (beyond any constraints, of course), I <i class="">think</i> this should be in phase 2… but I’m quite hazy on how generics work once the code’s been compiled, so maybe not.</div></div></div></div></blockquote><div><br class=""></div><div>Another way of modeling this might be to define a protocol, say “RepresentableInArray”, which implements get and set methods that take a pointer to a buffer, and an index. A default implementation in a protocol extension would just load and store the value. ‘Bool’ would define its own conformance which performs bitwise operations.</div><div><br class=""></div><div>However I think this is out of scope for stage 2 — it doesn’t fix any obvious major shortcoming in the language, it vastly complicates the implementation and it’s not required to achieve our ABI stability goals.</div><div><br class=""></div><div>Slava</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">- Dave Sweeris</div><div class=""><br class=""></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>