Iterate over Parameter Packs in Swift 6.0(swift.org)
swift.org
Iterate over Parameter Packs in Swift 6.0
https://www.swift.org/blog/pack-iteration/
3 comments
But the tuple still cannot conform to Equatable because it is not an "existential type"? It is pretty handy when you want to pass data around generic type T which is Equatable. Now if you want to add a little bit more data (through a tuple), it doesn't work any more because tuple of Equatable's cannot be Equatable itself.
This is a very cool feature, but I'm starting to see why people say that Swift has crammed every other language's feature into one place. Not that that's necessarily bad, but this is a pretty specific feature to have that probably won't benefit the majority of users (not that that's wrong either).
It will because of the mess of functions in some places. There are things in the std library defined like this:
a(x1);
a(x1, x2);
a(x1, x2, x3);
Etc. All the same function but with different numbers of arguments of the same type. I’m not sure how useful it is to everyday programmers, but it lets them fix some messes in the standard library. For example how you can only have 10 (?) things in a VStack in SwiftUI. Why? It was implemented as above because type checked variadic arguments weren’t doable for a reason I’m not sure of.
Now they are.
a(x1);
a(x1, x2);
a(x1, x2, x3);
Etc. All the same function but with different numbers of arguments of the same type. I’m not sure how useful it is to everyday programmers, but it lets them fix some messes in the standard library. For example how you can only have 10 (?) things in a VStack in SwiftUI. Why? It was implemented as above because type checked variadic arguments weren’t doable for a reason I’m not sure of.
Now they are.
Detailed rationale is in the Swift Evolution proposal (https://github.com/apple/swift-evolution/blob/main/proposals...)
This also isn’t a problem specific to Swift. Many strongly typed languages run into it.
Examples:
- C# (https://learn.microsoft.com/en-us/dotnet/api/system.tuple-8?...):
This also isn’t a problem specific to Swift. Many strongly typed languages run into it.
Examples:
- C# (https://learn.microsoft.com/en-us/dotnet/api/system.tuple-8?...):
public class Tuple<T1,T2,T3,T4,T5,T6,T7,TRest>
- Scala (https://www.scala-lang.org/api/2.13.6/scala/Function22.html): trait Function22[-T1, -T2, -T3, -T4, -T5, -T6,
-T7, -T8, -T9, -T10, -T11, -T12,
-T13, -T14, -T15, -T16, -T17, -T18,
-T19, -T20, -T21, -T22, +R] extends AnyRef
- Java (https://www.javatuples.org/index.html; third party)And thus Shapeless (https://github.com/milessabin/shapeless) was born.
Actually, it's used pretty heavily by SwiftUI. The DSL for SwiftUI relies pretty heavily on n-element tuples that were previously limited to something like 10 children. So you'd have something like:
This eliminates that. So even if you're not implementing it yourself, you're getting the benefits.
VStack {
ViewA()
ViewB()
...
ViewJ()
ViewK() // ERROR: A VStack is limited to 10 elements
}
The only way this could be implemented previously was with a separate init for each possible element count. A lot of auto-generated code.This eliminates that. So even if you're not implementing it yourself, you're getting the benefits.
Knowing nothing about Swift or SwiftUI, is there a reason the children of the VStack couldn’t be a list/array?
It's declarative, i.e. it needs to know what's in the list at IDE time. I can't explain more intelligently than that, though.
I agree its pretty niche; but i still think its better for users, who will probably never interact with it directly, than placing an arbitrary ceiling for certain functions
Having it for zip will be very nice for me in particular!
[deleted]