[swift-evolution] Yet another fixed-size array spitball session

[Brent Royal-Gordon]

> On Jun 4, 2017, at 6:56 AM, Daryle Walker via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Static-sized arrays should not be shoved into being a tuple with funny settings; that introduces subtleties into the tuple concept only because of jammed-in array support. The fact 3 separate-proposal-worthy features need to be introduced first,

The fact that I described the tuple-based alternative in more words than it takes to write "Just add a non-nominal fixed-size array type" doesn't mean that "Just add a non-nominal fixed-size array type" is actually a simpler proposal. As it often does, the word "just" hides a ton of complexity. Adding a non-nominal type is a *big deal*. There are only a few, and each one of them requires lots of special handling.

My proposal makes non-nominal types less special, then uses the reduced special-ness to add new functionality. Yours introduces additional special cases to add the new functionality.

> in which at least one is dubious in value (#2, since a lot of times the common type would be “Any”),

Yes, the subscript would sometimes be `Any`, or `CustomStringConvertible`, or `AnyHashable`, or a combination like `AnyHashable & Codable`. So what? Even `Any` is a useful type sometimes.

>> I think any complete solution depends on at least two more things:
>> 
>> 1. adding the ability to get an UnsafePointer to an immutable instance
>>   of value type
> 
> Do you mean something besides applying the address-of operator (I’m not sure what that is.) to “myArray.0”?

That would be `&myArray.0`, which isn't allowed if `myArray` is immutable, because it's designed for `inout` and merely overloaded for address-of. (Well, my understanding is that there are slightly deeper reasons too, but I'll let others explain that.)

-- 
Brent Royal-Gordon
Architechies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170606/66cb0cc2/attachment.html>