{"id":32293,"date":"2021-04-28T17:07:09","date_gmt":"2021-04-28T21:07:09","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=32293"},"modified":"2021-04-28T19:25:37","modified_gmt":"2021-04-28T23:25:37","slug":"swift-generics-2-existentials-boogaloo","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2021\/04\/28\/swift-generics-2-existentials-boogaloo\/","title":{"rendered":"Swift Generics 2: Existentials Boogaloo"},"content":{"rendered":"

Tim Ekl<\/a>:<\/p>\n

It’s been just over two years since we first saw “Improving the UI of\ngenerics<\/a>,” the discussion post about potential changes to make\ngeneric types easier to work with in Swift, and five<\/em> years since the first\nversion of the Swift Generics Manifesto<\/a>. (Time flies when you’re\nbuilding a language!) Last week, generics landed back in the spotlight, as\nAnthony Latsis, Filip Sakel, and Suyash Srijan proposed SE-0309<\/a>, with\na major change that addresses one of the most infamous errors in Swift:<\/p>

Protocol can only be used as a generic constraint because it has ‘Self’ or\nassociated type requirements.<\/p><\/blockquote>

While this change is still in review (through May 1), it looks very promising —\nbut, as often happens when dealing with the corners of the type system, the\ndetails can be a bit opaque. Much like last time<\/a>, this post\nwill walk through the nitty-gritty of the proposed changes in SE-0309, and offer\nsome practical scenarios where they might improve day-to-day Swift usage.<\/p><\/blockquote>\n\n

Previously:<\/p>\n