# Future of swift types

**URL:** <https://discourse.julialang.org/t/future-of-swift-types/22944>\
**Category:** Offtopic\
**Tags:** parametric-types\
**Created:** [April 9, 2019, 2:40am UTC](https://discourse.julialang.org/t/future-of-swift-types/22944 "2019-04-09T02:40:01Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![datnamer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/datnamer/32/3471_2.png) [@datnamer](https://discourse.julialang.org/u/datnamer)\
**Post date:** [April 9, 2019, 2:40am UTC](https://discourse.julialang.org/t/future-of-swift-types/22944/1 "2019-04-09T02:40:01Z")

</div>

> **[Improving the UI of generics](https://forums.swift.org/t/improving-the-ui-of-generics/22814/19)**
>
> Thanks @Joe\_Groff, I love the direction this is taking, but I’m concerned that in it’s current form it’s introducing too much syntax (without reducing other syntax). Sorry if this is better suited for a different thread, but there didn’t seem to...

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [April 9, 2019, 7:41am UTC](https://discourse.julialang.org/t/future-of-swift-types/22944/2 "2019-04-09T07:41:17Z")

</div>

Would you mind explaining what this is about?

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [April 9, 2019, 1:44pm UTC](https://discourse.julialang.org/t/future-of-swift-types/22944/3 "2019-04-09T13:44:35Z")

</div>

It’s interesting to read the first post in that thread if only to realize how much more simply Julia achieves the same functionality as “existential types” (= container for an abstract type, maybe parametrized by a trait) and “reverse generics” (= callee decides on return type). This is not a criticism of the Swift developers, however—statically typed languages are simply much more constrained.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [April 9, 2019, 2:00pm UTC](https://discourse.julialang.org/t/future-of-swift-types/22944/4 "2019-04-09T14:00:32Z")

</div>

My biggest issue with static PL proponents is that there’s an ongoing collective refusal to acknowledge that static type checking is not all upside. Especially once you get into generics and higher order programming, the design and implementation cost of being **required** to be able to type check every valid program is simply staggering. One of the worst symptoms of this problem can be seen in the massive difficulties that practical static languages keep having with their collections libraries. In this case it’s Swift, but Scala has famously had [major problems](https://www.youtube.com/watch?v=uiJycy6dFSQ) in this area (that was some years ago, I’m not sure where they’re at now). Go, even more famously, has simply refused to add generics—if I’m interpreting it correctly, precisely to avoid this whole morass.

Yes, being able to check types for any possible program at compile time is a nice property, but at what cost? If Julia has proved one thing with regard to programming language design, it’s that you can get a huge amount of benefit from a type system without using it for static type checking at all. Maybe that’s not the primary thing type systems should be designed for. Heck, maybe you should be _allowed_ to call something “a type system” even if it’s not primarily intended for static type checking!

---

<div class="post-metadata">

**Author:** ![bpr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bpr/32/2710_2.png) [@bpr](https://discourse.julialang.org/u/bpr)\
**Post date:** [April 9, 2019, 3:05pm UTC](https://discourse.julialang.org/t/future-of-swift-types/22944/5 "2019-04-09T15:05:53Z")

</div>

I understand your position, but IMO you’re not being entirely fair. Go 2.0 supposedly will add [generics](https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md), which are practically a necessity for any statically typed language, and Paul Phillips’ issues with Scala development were not really about the impracticality of typing generics. Sure, the cost of getting all of this right and implemented is high, but [“It takes a tough man to make a tender chicken”](https://www.youtube.com/watch?v=uN37i9qr0zY).

That said, yes, it’s obvious that neither static typing and dynamic typing are all upside. I really like the way that Julia took another position in the space, and I hope that in the future some external tooling can be used to get more of the benefits of static typing without compromising Julia’s dynamic nature. I’ve been happily surprised with Julia code that that I wrote that was unexpectedly polymorphic in a useful way.

Another example of this kind of collective refusal to see the other side in PL design s with respect to tracing garbage collection. The pendulum has swung back and forth there quite a bit too.