19 comments

[ 2.2 ms ] story [ 63.5 ms ] thread
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.

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?...):

  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)
(comment deleted)
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
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:

  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.
Having it for zip will be very nice for me in particular!
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.
[flagged]
Better cross-platform would be nice but it will succeed regardless given resources and level of commitment from Apple.
Does Swift really compete with those languages?

As I understand, it's pretty much just there so that people can write software for MacOS/iOS without needing to use Objective C.

It absolutely competes if the non-Apple ecosystem is improved. And Apple has put some support into running Swift in Linux, just not enough.

A big thing Swift has over all these languages is that it's higher-level than Rust and Zig, but not garbage-collected unlike Scala, Kotlin, and Go. Personally, I would use it if it wasn't for its dependence on Apple and that I use IntelliJ and they are discontinuing AppCode.

Reference counting is a garbage collection strategy, otherwise python too would be non-gc language (cpython).
ARC is very limited in swift (mostly classes) most of the other types are value types that doesn't use ARC, also most folks don't consider ARC to be GC as there is no garbage to be collected.
Kotlin, Scala, and Go are garbage collected. Zig is a language that barely even has name recognition outside a certain niche that loves it.

Swift vs Rust is a real question. Currently Rust is almost always the answer outside of the Apple ecosystem, but that may change. It's a great language that could use some better tools.

(comment deleted)