[swift-evolution] Three quick(ish) generics enhancements; *maybe* phase 1

[David Sweeris]

> On Dec 23, 2016, at 03:13, Tino Heth <2th at gmx.de> wrote:
> 
> 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 ;-)
> 
> 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".
> I'm to lazy to fight with the medium to find a reference, but there is a draft for a proposal:
> https://github.com/SwiftInofficialEvolution/Home/wiki/compile-time%20parameters
> 
> 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>.
> 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.
> 
> 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.

Yes, that's one of the proposals I was thinking of!

I think if the type was specifically an "IntegerLiteral", the restriction would be more obvious. 'IntegerLiteralType' would be better, but it's just typealiased to 'Int', so maybe not better enough.

It occurs to me that it might 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.

That "opposite of inout" thought is quite interesting... I'll have to think about it for a while.

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161223/dab3670b/attachment.html>