> On Dec 23, 2016, at 03:13, Tino Heth <[email protected]> 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_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
