<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="">(Disclaimer: This might actually just be a slightly disguised subset of the “allow non-type generic parameters” idea, depending on whether that includes stuff like this:</div><div class=""></div><blockquote type="cite" class=""><div class="">var foo = 2</div><div class="">var bar = Vector<foo>()</div></blockquote><div class="">or if it only addresses this:</div><div class=""></div><blockquote type="cite" class=""><div class="">var bar = Vector<2>()</div></blockquote><div class="">)</div><div class=""><br class=""></div>Building on “pure" from: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003684.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003684.html</a><div class=""><br class=""></div><div class="">Consider this function:</div><div class=""><blockquote type="cite" class="">func @pure foo<T,U,V>(_: T.Type, _: U.Type) -> V.Type {…}</blockquote></div><div class=""><br class=""></div><div class="">Since @pure prevents foo from accessing global/static variables, since it can only call other @pure functions, and since its only parameters are themselves other types, then the return type of V must solely depend on the *types* T and U (and what can be gotten from T & U using @pure functions). While this is not the same thing as “known at compile time”, it does (I think) guarantee that V can be deduced only using what is known about T and U *at compile time*. If the return value of such a function could used as a “proper” type (i.e., it could be used like “var bar: foo(Int.self, String.self)”, for instance), it wouldn’t so much remove the “types must be known at compile time” restriction, as it would give the programmer a powerful way to tell the compiler *how* to figure out what the type is.</div><div class=""><br class=""></div><div class="">The use case I’m thinking of is admittedly pretty narrow… I personally want this feature to help with a work-around I’m using for Swift not having non-type generic parameters:</div><div class=""></div><blockquote type="cite" class=""><div class="">protocol IVAT { //Integer Value As Type</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>static var integerValue:Int {get} </div><div class="">}</div><div class="">struct _0 : IVAT { static let integerValue = 0 }</div><div class="">struct _1 : IVAT { static let integerValue = 1 }</div><div class="">struct _2 : IVAT { static let integerValue = 2 }</div><div class="">//…etc</div><div class=""> </div></blockquote><div class=""><blockquote type="cite" class="">struct Matrix<M:IVAT, N:IVAT> {</blockquote><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>private var backing = [[Double]](count: M.integerValue, repeatedValue: [Double](count: N.integerValue, repeatedValue: 0.0))</blockquote><div class=""><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>subscript(row: Int, col: Int) -> Double {}</blockquote></div><blockquote type="cite" class="">}</blockquote></div><div class=""><br class=""></div><div class="">If we allowed pure functions to return “usable” types, then Matrices could be joined like this:</div><blockquote type="cite" class=""><div class="">func @pure + <T: IVAT, U: IVAT, V: IVAT> (_: T.Type, _: U.Type) -> V.Type {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>switch (T, U) {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case (_0, _0): return _0.self</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>case (_0, _1): return _1.self</div></blockquote><blockquote type="cite" class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>…</div></blockquote><blockquote type="cite" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>default: return _0.self<br class=""></blockquote><blockquote type="cite" class=""><div class="">}</div></blockquote><blockquote type="cite" class=""><div class="">// joins two matrices… join([[1,2],[3,4]], [[5],[6]]) would return [[1,2,5],[3,4,6]] </div><div class="">func join <M:IVAT, N1:IVAT, N2:IVAT> (lhs: Matrix<M,N1>, rhs: Matrix<M, N2>) -> Matrix<M, N1.self + N2.self> {…}</div></blockquote><div class=""><br class=""></div><div class="">Again, I realize the use case I’ve presented is pretty narrow (and one that’ll hopefully become a moot point later), but it seems like this would be a *very* expressive way to expand the power of generic types.</div><div class=""><br class=""></div><div class="">Anyway… Yay? Nay? Implementation-wise, my first thought is to embed the REPL in the generic specialization system then use the function in question as its input to extend the generic specialization system, but I don’t know if that’s the right place to handle it, let alone if that’s a feasible idea.</div><div class=""><br class=""></div><div class="">-Dave</div></body></html>