I think this proposal is trying to do too much at once.  Correct me if I’m 
wrong, but you’re proposing

1) New sugar for fixed-length arrays without a corresponding stdlib declaration
2) Arity and type inference for literals
3) Default initialization semantics for arrays including a DI exception for 
fixed-length arrays that aren’t fully initialized 
4) 2 new attribute declarations for unspecified concurrency semantics
5) A magical compiler intrinsic that declares loop counters
6) Static collection subtyping constraints referencing convertibility 
constraints we don’t currently have
7) Tuple conversions

I believe your aims are noble, and this is certainly a tremendously important 
problem we need to solve, but I think there needs to be a measured response to 
the current state of things.

~Robert Widmann

> On Jul 10, 2017, at 9:54 PM, Daryle Walker via swift-evolution 
> <[email protected]> wrote:
> 
> Spent the past week coming up with a full proposal for fixed-size arrays. I 
> wrote it mainly from the bottom upwards. There may be some inconsistencies. 
> And I'm not entirely sure what "structural sub-typing" means, or if it's 
> appropriate for arrays.
> 
> <https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb 
> <https://gist.github.com/CTMacUser/cfffa526b971d0e1f3a079f53c6819bb#file-nnnn-fixed-size-arrays-md>>
> 
> Sent from my iPad
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to