It amazes how people completely ignore everything against some one thing they can potentially defend.

Once again, SwiftUI exposes deficiencies in the language, no matter if you care about it or not. Let's take it from the top, shall we?

- Swift UI says: hey, I need to have a list of values inside my nice little functions, what can yo give me? Swift: I can give you Java:

  static func buildBlock<C0, C1>(C0, C1) -> TupleView<(C0, C1)>

  static func buildBlock<C0, C1, C2>(C0, C1, C2) -> TupleView<(C0, C1, C2)>

  static func buildBlock<C0, C1, C2, C3>(C0, C1, C2, C3) -> TupleView<(C0, C1, C2, C3)>

  static func buildBlock<C0, C1, C2, C3, C4>(C0, C1, C2, C3, C4) -> TupleView<(C0, C1, C2, C3, C4)>

  static func buildBlock<C0, C1, C2, C3, C4, C5>(C0, C1, C2, C3, C4, C5) -> TupleView<(C0, C1, C2, C3, C4, C5)>

  static func buildEither<TrueContent, FalseContent>(first: TrueContent) -> _ConditionalContent<TrueContent, FalseContent>

  static func buildEither<TrueContent, FalseContent>(second: FalseContent) -> _ConditionalContent<TrueContent, FalseContent>

  static func buildIf<Content>(Content?) -> Content?

Once again, the only reason `some` exists is to aid the compiler. Because the compiler in "the best designed language" cannot figure out the difference between protocols and types on its own.

In general, in Swift and you have to constantly manually aid the compiler in everything. Also see `guard` below.

> Your "favorite piece of code" (which, FWIW, is missing an else on the guard) has different semantics than the other snipped you present because it rebinds self to a non-optional type, whereas the second one doesn't.

Yeah, yeah. I've seen the "it's different semantics" argument everywhere. It's not "different semantics". The only reason this exists is because they rushed the language out, and the compiler and the type checker was very limited. The only reason guard exists is to force nullability checks by the compiler. It's an inelegant and clunky clutch to aid the compiler. That is it. "The best designed language" could instead have this:

   if x == nil { return }

   // the compiler knows that x is now not nil, 
   // it's no longer an optional type beyond this point

No I'm not going to bring it up, but it's funny how you brought it up.

Actually, the reason I chose to refuse to engage with you about SwiftUI is that Swift doesn’t support ever programming paradigm in existence, nor should it. The fact that SwiftUI is running into issues where it is trying to use language features that don’t exist and then shoehorn them into the language retroactively is not really a great situation. That said, you claiming (multiple times!) that the language had no thought put into it and that it’s the same as Java is just outright trolling/bait at this point. The language has had a huge amount of effort put into it, many of the questionable decisions made earlier have been rolled out; at this point its type system is really at a similar place Rust or Scala’s is.

The lack of conditional statements being expressions (note: the ternary operator does exist) and type narrowing is a conscious choice, not something that the language has to have in order to “be modern” or some sort of evidence that this wasn’t considered. Type narrowing in particular is very common in languages that interface with code that is not well typed (TypeScript with untyped JavaScript, Kotlin with unannotated Optionals and inheritance hierarchies from Java) and Swift has generally had a much better interface with system libraries than that (this being largely controlled by Apple, they can roll out annotations fairly widely). Statement expressions are just a choice that Swift does not choose to have, although as see with function builders perhaps Apple will force it into the language anyways. And type erasure is good not only for the compiler but it’s also a huge benefit for users and API designers: it allows for “class cluster” designs, it keeps users from having to see SomeMonsterGeneric<Wrapper<Type1, Type2, Type3>, OtherGarbage> for no reason.

Of course it shouldn't. But going ahead and saying that "we shouldn't look at SwiftUI" for whatever reason stops most of the discussion about the deficiencies in the language.

Look, even you are saying things like this:

-- start quote --

The lack of variadic generics is an annoying limitation...

The fact that SwiftUI is running into issues... and then shoehorn them into the language retroactively is not really a great situation.

-- end quote --

You are basically repeating my words, but somehow I'm wrong in my assessment.

> that the language had no thought put into it and that it’s the same as Java is just outright trolling/bait at this point.

When you say that "lack of variadic generics is an annoying limitation" and "language features that don’t exist and then shoehorn them into the language retroactively" it's all right. When I say the same things, it's trolling. Got ya.

> The lack of conditional statements being expressions (note: the ternary operator does exist) and type narrowing is a conscious choice, not something that the language has to have in order to “be modern”

That's why SwiftUI has to "retroactively shoehorn" things like `buildEither<TrueContent, FalseContent>` because a "best designed language" doesn't have any facilities to, well, facilitate this.

> although as see with function builders perhaps Apple will force it into the language anyways.

Me: Swift lacks this and that.

You: You are a troll, and you are wrong, and this is a good design decision <literally half a sentence later> it will likely become a part of the language because <a few paragraphs before> there are features that don't exist in the language

> And type erasure is good not only for the compiler but it’s also a huge benefit for users and API designers: it allows for “class cluster” designs, it keeps users from having to see SomeMonsterGeneric<Wrapper<Type1, Type2, Type3>, OtherGarbage> for no reason.

There's literally no reason to have SomeMonsterGeneric<Wrapper<Type1, Type2, Type3>, OtherGarbage>. The only reason `some` exists is, and I repeat myself, because the compiler and the type checker literally can't distinguish between a type and a protocol without the developer babysitting them.

The reason I suspect trolling is that you have repeatedly taken my comments out of context, glommed them with other things that are not related, and then responded to that strawman, plus created what I can only refer to as "bait" because I have to waste my time responding to them when I could be having a much more productive conversation. So tell me, would you rather talk about how Swift's type system is the same as Java, how the compiler is designed by incompetent fools who rush out releases, and how any language that doesn't include the three features you brought up is automatically stupid, or maybe we can discuss this more productively from the viewpoint of "why didn't Swift include these things I like?" or "was SwiftUI poorly designed if it is trying to create new parts of the language out of thin air to support itself?" or "has Swift prioritized the wrong set of features?"