3 ms·
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 nam
by comex 8y 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.)
- saagarjha 8y agoYou 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 https://twitter.com/jckarter/status/1115343308782358528
- twic 8y agoIs `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 8y 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.
- skohan 8y agoI 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
- slavapestov 8y agoIn 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.
- pcwalton 8y agoNot a coincidence. There are people who work on Swift who worked on Rust, and vice versa.