> On Jun 4, 2017, at 6:56 AM, Daryle Walker via swift-evolution > <swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
