Improving the UI of generics

Evolution Discussion
22

Thank you so much for the great write up. I think I grokked the concept decently with the opaque return types thread, but this still helped :slight_smile:
I like a lot about this:

  • the fact that before generics was the "low level" way of doing things, more syntax but more power, to approach with caution. While existential were the "nice" way since the syntax is so straightforward
  • Given that as highlighted both are ways of defining type constraints, it's better to have them more similar looking so that an user can actually think of which they want to use instead of going for the most convenient (apart from current PAT issues)
  • the fact that constraints can be defined on the types themselves
  • extension any Hashable: Hashable is quite interesting as it actually defines what's happening

There are some things I'm not too sold on though:

  • Using type(of:) suggests the dynamic type of something, while in this case we're talking about static type. I actually use it quite a bit in inits and never understand the rules around when it can be used as a statically evaluated utility and when as a runtime one
  • Especially type(of: return) looks like an hack :cry:

Also just a few questions:

  • func foo <T> (_ t: T) translates to func foo(_ t: some Any) or func foo(_ t: some)?
  • Would this allow extension any Any?
  • Should then current mixins like extension Collection { ... } be extension some Collection { ... } instead?
  • Can properties be some without making the type itself generic? Sounds like it would be some kind of implicit genericness...
1 Like