3 ms·
Type Erasure Magic in Swift
- danra 10y agoAs a TL;DR, or even as a starting point for diving deeper into the finer points in the talk, it would be really helpful to attach the complete code which demonstrates type erasure.
- deleted 10y ago[deleted]
- bpicolo 10y agoWhy do all sorts of blogs have "Click to Read More" buttons these days? Seems totally unnecessary.
- Someone 10y agoIt makes the adverts stand out more, and that pays the bills. Edit: it seems the old location for adverts, the sidebar, is dead because people zoom in on mobile and many users are on mobile. Pop-ups also are somewhat dead because people have learned to close the not-too obnoxious ones without paying attention.
- rezashirazian 10y agoI think it's a way to count article reads and general engagement on the page.
- scott_s 10y ago> In Java it is used to let the compiler know and it will erase the <T> and make it a concrete type. It's the opposite. In Java, when you instantiate a generic class with a concrete type, it will erase that type in the generic class. So, the actual code for Foo<String> and Foo<Integer> is the same; String and Integer are erased, and inside of Foo, it just uses Object. For that reason, Foo<T> is not allowed to do anything with T that would require knowing the actual type of T; that knowledge has been erased. See https://docs.oracle.com/javase/tutorial/java/generics/erasure.html https://docs.oracle.com/javase/tutorial/java/generics/erasur... With this confusion, it's hard for me to orient myself with how this applies to Swift.
- catnaroek 10y agoThis seems like an apology for the unforgivable: type erasure is a language implementation detail, and thus it shouldn't affect language users. A user might want to choose an implementation that uses monomorphization for performance reasons, or an implementation that doesn't erase types for debuggability reasons. But the language implementor's choice to use type erasure shouldn't affect the meaning of code written by language users.