Swift Generics Evolution

https://www.timekl.com/blog/2019/04/14/swift-generics-evolution/

by mpweiher • 7 years ago

80 100 7 years ago

iddan• 7 years ago

Swift is so awesome! If it was simpler to start a non-UI project and compile time was shorter I would have definitely joined onboard.

skohan9• 7 years ago

If it was simpler to start a non-UI project

You can do it in one command:

    $ swift package init --type executable

zapzupnz• 7 years ago

And then to make that project openable in Xcode:

    $ swift package generate-xcodeproj

tokyodude• 7 years ago

what makes it awesome? reading the spec nothing sticks out. I often wonder if it's just ObjC survivor bias but if there is anything that makes it actually special I'd love to know.

saagarjha8• 7 years ago

It has (IMO) pretty and consistent syntax for many programming paradigms. Most of the language decisions seem like they were given significant thought. Swift is a great language to read and write because it strives to be pleasant for both cases.

nicoburns• 7 years ago

I often wonder if it's just ObjC survivor bias but if there is anything that makes it actually special I'd love to know.

It's definitely not just this. Swift is very similar in design to Rust, and has a lot of the same goodies like an ML-inspired type system, but without the complications imposed by the borrow checker / lack of GC.

omeid23• 7 years ago

Light syntax, algebraic datatypes, type parameters, very solid enumeration, the whole ObjC library ecosystem, semi-decent (compared to Haskell/OCaml et. al) pattern matching, immutable and mutable data structures (Array vs ArraySlice for example).

twic2• 7 years ago

It's a decent language, if nothing particularly special. It's like a slightly fresher Java or C#. Survivor bias and standard-issue Apple fanboyism give it some extra shine.

the_duke4• 7 years ago

Swift is a really cool language. Quite similar to Rust, but easier to use. ( GC, no borrow checker, no multi-threading safeguards, ...)

I just wish cross platform support was a real priority. The Ubuntu packages are all there is, and much of the ecosystem is centered around (Mac/i)OS.

pjmlp13• 7 years ago

Kotlin/Native might turn out to be that, but it depends pretty much where JetBrains is willing to take it.

In any case, as rule of thumb, systems languages that come with an OS/platform usually win in the long run.

jfk13• 7 years ago

I don't really see how "quite similar to Rust" and "GC, no borrow checker, no multi-threading safeguards" can both be true at the same time.

omeid23• 7 years ago

They're both highly influenced by ML family of languages.

skohan9• 7 years ago

They both have similar goals as far as mitigating certain classes of runtime errors through static checks. Both have nice type systems, and features like explicit mutability and nullability.

Like you say the approach is pretty different: when it comes to the tradeoff between safety/performance and developer ergonomics Rust leans toward the former where Swift leans toward the latter.

0815test2• 7 years ago

It's quite similar to Rust... if Rust literally used Arc<Mutex<T>> everywhere. And Arc<Mutex<T>> everywhere might actually have lower throughput than tracing GC! (Though it's arguably preferable for low-latency code, so it might make some sense for the typical use cases of ObjC and Swift.)

mnem• 7 years ago

If GC means garbage collection here, Swift definitely doesn't have that.

pjmlp13• 7 years ago

Sure it does, reference counting is a GC implementation algorithm from CS point of view.

The Garbage Collection Handbook, chapter 5.

http://gchandbook.org/

Just one key CS reference for compiler writers among a few others.

_frog• 7 years ago

Swift doesn't actually use garbage collection, it uses a variant of Objective-C's Automatic Reference Counting (ARC) which was introduced a few years prior to Swift.

saagarjha8• 7 years ago

If we’re being pedantic, Automatic Reference Counting is a form of garbage collection.

tambourine_man3• 7 years ago

Whenever possible, I like using tech that I can mostly understand.

A small simple language is something Swift is not.

saagarjha8• 7 years ago

Swift aims to be useful even if you don't understand parts of it by the principle of progressive disclosure.

duncanawoods• 7 years ago

Hardly. Trying to read someone else’s code is “smack you in the face with a book” disclosure.

Go/C# pose no issue but things like c++ cause total wtf where other people’s taste/habits become mutually unintelligible dialects.

ken• 7 years ago

And that is an interesting experiment and perhaps a worthy goal, but having used Swift for a few years now, I don't think they succeeded at this. I'd say it demonstrated that "progressive disclosure" may be a great concept for games, or apps, but there's just way too much difference between someone new to programming and a professional programmer for a language to cover all these cases. Apple doesn't even have a non-pro Final Cut any more.

Even in my first few days, having read Apple's Swift documentation, I had to continuously resort to StackOverflow for answers, which frequently sent me to the language grammar (which had many mistakes in it, and I think still does), and the Swift bug tracker. The inflection point on the learning curve is right after "hello world", which makes for great demos, but that's it.

Personally, I think even Common Lisp does a better job at progressive disclosure. There's huge areas of CL that you can simply ignore. I worked in CL for years before I bothered to learn about conditions, special variables, or 90% of LOOP's features. In Swift, almost right away I had to read everything related to errors. You can't ignore it, except in the simplest program.

I studied generics in college, as part of my data structures class, or maybe my compilers class. I've watched Alexis Gallagher's "PATs" video at least 3 or 4 times. I still don't understand Swift generics. Or maybe I understand what tools are provided, but I don't understand why you'd build (or want) a tool that makes it so hard to, say, define a new type with an "isEqual" method to determine if it's the same as another.

Every Swift programmer hits the "protocol can only be used as a generic constraint" phase pretty quick. My complaint with Swift generics was never that they're too simple. It would be great if this were just a corner that PL/type-system geeks could geek out on, but it's an area that you can't ignore.

melling• 7 years ago

What’s your ideal simple language?

I’d argue that with type inference, immutability, and non-null as a default, Swift is an easy language for anyone to be productive quite quickly.

    let x = “I’m immutable and not null”

    let favorite = [“Java“, “Perl”, “Swift”].shuffled().first

romanovcode2• 7 years ago

Why is `shuffled()` a function and `first` a property? Seems weird and not simple.

vbezhenar3• 7 years ago

My ideal simple language is Java 1.4 without checked exceptions.

tambourine_man3• 7 years ago

Certainly not one with optionals. I still don’t see the need for it. I can check for nullability myself when it’s required.

Genetics are indeed useful but such a can of worms that are not worth it IMO

omeid23• 7 years ago

That works only until what you can "understand" and "want" changes.

I really like to learn everything about every tech that I use, bordering on obsession, and after a few solid times that I hit roadblocks or had to fight with the tool because it is too "simple", I started to grok the difference of "simple" and "easy".

wool_gather5• 7 years ago

the difference of "simple" and "easy"

Don't know if you were already referring to Rich Hickey's talk on this, but if you weren't, it might appeal to you. Simple Made Easy: https://www.infoq.com/presentations/Simple-Made-Easy

"Okay, the other critical thing about simple, as we've just described it, right, is if something is interleaved or not, that's sort of an objective thing. You can probably go and look and see. I don't see any connections. I don't see anywhere where this twist was something else, so simple is actually an objective notion. That's also very important in deciding the difference between simple and easy."

TazeTSchnitzel• 7 years ago

Is this describing something similar to how Haskell's return types work?

r-w• 7 years ago

How so? I know Haskell has pretty extensive type inference, but I’m not sure exactly how it relates here.

bsaul• 7 years ago

I haven’t followed C# for a long time, but i remember the type system beeing both obvious and powerful. Could anyone here explain what is swift trying to accomplish here that just copying the C# way wouldn’t be enough ?

_old_dude_• 7 years ago

I see two use cases, Swift is a precompiled language unlike C# or Java so a call to a method through a protocol (an interface) can not be inlined. Let suppose you have an interface IList and an IEnumerator,

  interface IList<T> {
    IEnumerable<T> iterator();
  }

it means that despite the fact that you may know the exact implementation of the IList, you have no idea of the exact type of the method iterator() at compile time because it's hidden behind an interface.

Enter the existential types,

  interface IList<T> {
    type IEnumerator<T> Iterator;  // this is a type declaration

    Iterator iterator();
  }

now if you have an implementation of IList, you will have

  class FunnyList<T>: IList<T> {
    type FunnyListEnumerator<T> Iterator;

    Iterator iterator();
  }

so at compile time, when you use a FunnyList, the compiler knows the exact type of the method iterator().

The other usual use case, which is a restricted version, is to be able to specified the variance at use site, like the wildcards in Java (List<? extends Foo>) which is a way to specify that you don't want a method to be parameterized but you want a type of a parameter to be covariant

  void foo<T:Foo>(List<T> list)  // the method is parameterized

  void foo(List<some Foo> list)  // the type is parameterized

C# doesn't have variance at use site, only at definition site with 'in' and 'out', Kotlin has both. Scala and C++ with type name form.

pjmlp13• 7 years ago

C# and Java also have AOT compilers available.

In fact that is their execution model in UWP, Unity (Consoles, iOS, Xamarin (iOS), Android and some embedded deployments.

comex• 7 years ago

I've always thought of Swift as a sort of "sister language" to Rust, since so many features have almost the same semantics and syntax, but with some keyword names switched around and slightly different punctuation.

These proposed changes continue in that vein :)

- As the post notes, `any Shape` is the same as Rust's `dyn Shape` - both languages originally allowed you to write simply `Shape` (i.e. a trait/protocol name) to get an existential type, but later decided that was confusing.

- `some Shape` is the same as Rust's `impl Shape`.

- `Shape<.Renderer == T>` is equivalent to Rust's `Shape<Renderer=T>`.

(This is not meant as a criticism of Swift; Rust has copied some things from Swift as well. Just interesting to note.)

saagarjha8• 7 years ago

You may have noticed that Swift’s keywords have the same length as Rust’s. This isn’t an accident, apparently: https://twitter.com/jckarter/status/1115343308782358528

twic2• 7 years ago

Is `some Shape` actually the same as `impl Shape`? In Rust, `impl Shape` means "a fixed, statically knowable type which implements Shape, and which the implementation of this function knows but its callers do not". I get the impression that in Swift it means "one of the possible numerous which implements Shape, chosen at runtime by the implementation, and returned to the caller as an existential".

I may have misunderstood what is planned for Swift though.

Lukasa• 7 years ago

`some Shape` is literally identical to `impl Shape`, including the semantics you discuss above. The compile-time return value of a function returning `some Shape` must be the same on all execution paths. It just avoids expressing to the caller what it is.

Incidentally, this in principle allows the optimiser to specialise the caller to the return type of this function, avoiding the existential altogether.

skohan9• 7 years ago

I believe that's incorrect. Swift generics deal with statically-knowable types.

My reading was:

`some` -> Some specific type with these constraints which will be known at compile time

`any` -> Any value conforming to these constraints which may vary at runtime

pcwalton• 7 years ago

Not a coincidence. There are people who work on Swift who worked on Rust, and vice versa.

tsss2• 7 years ago

I don't get the motivation behind this. I assume Swift has subtype polymorphism, so why not do this:

  func allEncompassingShape() -> Shape {
    return SpecialGiantShape()
  }

This function returns some type that may be a subtype of Shape.

jakobegger• 7 years ago

Because that does not work with generic protocols. You can't have a function return a sequence:

    func make_numbers() -> Sequence<Int> {
     // Cannot specialize non-generic type 'Sequence'
    }
    func make_numbers() -> Sequence {
     // Protocol 'Sequence' can only be used as a generic constraint because it has Self or associated type requirements
    }

Whereas with this change you probably could at some point do something like this:

    func make_numbers() -> some Sequence<.Element == Int>

tsss2• 7 years ago

What about

  func make_numbers() -> Sequence<Any>

This should work as long as Sequence is covariant on Element. You could return any possible Sequence here, like Sequence<Int> or Sequence<Double>. The user of the function wouldn't know.

You could also do something like

  func make_numbers() -> Sequence<Comparable&PartialOrder>

dep_b6• 7 years ago

Working with Generics in Swift often made me feel I was missing something, pushing me to refactor my code once things started pushing past the trivial usage of generics because types started fighting back. Indeed I noticed that the requirement that types are declared “from the outside” made things harder.

Another thing is combining protocols with generics. That feels a lot more convoluted than might be necessary.

Seeing people express exactly what is the problem and what could be a solution is impressive. I hope we’ll see reverse generics soon.

Swift Generics Evolution

Related Stories