Fixed-size arrays have been discussed on this list in the past; the core team settled on a syntax of `4xInt` (Int array of length 4), which is apparently already the spelling that's used in LLVM. Not sure what happened to that discussion; I seem to recall that it was just a matter of not having enough engineering resources to implement.<br><br>Default values and constants in generics are already listed on the Generics Manifesto; I assume that means the core team thinks they're fine ideas, and they'll be proposed and implemented if engineering resources permit...<br><br><div class="gmail_quote"><div dir="ltr">On Fri, Dec 23, 2016 at 11:56 David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">On Dec 23, 2016, at 03:13, Tino Heth <<a href="mailto:2th@gmx.de" class="gmail_msg" target="_blank">2th@gmx.de</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg">My personal theory of the whole phase-one construct is that it's just a way to calm everyone down, so that there is more time to actually do some work on the code ;-)<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Afair, the conversation about this didn't fade out slowly, but was stopped by someone saying "that addition is to big to be considered now".</div><div class="gmail_msg">I'm to lazy to fight with the medium to find a reference, but there is a draft for a proposal:</div><div class="gmail_msg"><a href="https://github.com/SwiftInofficialEvolution/Home/wiki/compile-time%20parameters" class="gmail_msg" target="_blank">https://github.com/SwiftInofficialEvolution/Home/wiki/compile-time%20parameters</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I think the idea is quite useful, but it might be confusing for some people that they can create Vector<Int, size: 4> but not Vector<Int, size: myIntValue>.</div><div class="gmail_msg">The issue with the latter is obvious when you fully understand the concept, but if myIntValue is known to be a constant at compile time (or a fixed case of an enum…), it's harder to decide wether the compiler should accept it.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In some aspect, the parameters have requirements that are opposite to "inout" — but that's a very fresh thought, and I've no idea if that duality might help.</div></blockquote><br class="gmail_msg"></div><div dir="auto" class="gmail_msg"><div class="gmail_msg">Yes, that's one of the proposals I was thinking of!</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I think if the type was specifically an "IntegerLiteral", the restriction would be more obvious. <span style="background-color:rgba(255,255,255,0)" class="gmail_msg">'IntegerLiteralType' would be better, but it's just typealiased to 'Int', so maybe not better enough.</span></div><div class="gmail_msg"><span style="background-color:rgba(255,255,255,0)" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg">It occurs to me that it <i class="gmail_msg">might</i> be possible to create a 'Vector<Int, size: myIntValue>' by considering 'Vector<Int, size:_>' to be a kind of "implicit protocol" (and one with a generic parameter, "Int", no less!) to which all concrete instances of Vector would conform. Then we could write "func foo(x:Int)->Vector<Int, Size:_> {...}" and it'd just work. I think... maybe not... I haven't thought about it longer than it's taken to write out.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">That "opposite of inout" thought is quite interesting... I'll have to think about it for a while.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- Dave Sweeris</div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>