Swift Generics Evolution

Re:Swift Generics Evolution by twic on Monday April 15, 2019 @06:49AM (#19664424)

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.

[ Parent | on HN ]

Re:Swift Generics Evolution by Lukasa on Monday April 15, 2019 @06:53AM (#19664436)

`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.

[ Parent | on HN ]

Re:Swift Generics Evolution by skohan on Monday April 15, 2019 @06:54AM (#19664441)

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

[ Parent | on HN ]

Re:Swift Generics Evolution by slavapestov on Monday April 15, 2019 @09:16AM (#19665043)

In the current “opaque types” prototype implementation `some` still hides the implementation of the type across module boundaries, meaning it can be changed without recompiling clients. The specific guarantee is that (in a single process execution) each invocation of a some-returning function returns the same concrete type.

[ Parent | on HN ]