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

[Xiaodi Wu]

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.

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...

On Fri, Dec 23, 2016 at 11:56 David Sweeris via swift-evolution <
swift-evolution at swift.org> wrote:

>
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161223/2445cbd6/attachment.html>