[swift-evolution] Yet another fixed-size array spitball session
brent at architechies.com
Tue Jun 6 12:55:48 CDT 2017
> 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution