Le 20 févr. 2017 à 1:19, David Sweeris <daveswee...@mac.com> a écrit : > > On Feb 19, 2017, at 21:19, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> This is very, very interesting. Thank you so much for the text. >> >> If I understand your take correctly, the benefits of `pure` in Swift would >> be contingent on how pervasively it can be used (as it's the composability >> of pure functions that gives it exponential value). And, based on your >> discussion, very few functions in Swift would be compiler-provably pure [...] > > I think this might, at least partly, be because we can't restrict generic > parameters to be value types.
That's somewhat a problem. But think a bit about the copy-on-write containers. Because the compiler itself has no notion of copy-on-write semantics, the compiler can't prove that COW types behave correctly as value types. The optimizer would have to make the pessimistic assumption that dereferencing the pointer is possibly a dependence on external state, making the function unoptimizable. Basically, any struct with a pointer (or object reference) would need to be vouched for with a "trust me" attribute, or not be vouched for if it doesn't fit value semantics. And, as you say, generic containers value-typeness will depend on their generic arguments. But... keep in mind that for the purpose of evaluating whether a function is pure (as in strongly, optimizable pure), what matters really is not the type but what you do with it. `Optional<AnyObject>` is not what you would call a value type, but it does behave as a value type as long as you only compare it to `nil`, since you never access the object. D doesn't make this fine-grained distinction and is fine in most cases because it has transitive immutability. Swift doesn't have that, so maybe we should try something a bit different. -- Michel Fortin https://michelf.ca _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
