[swift-evolution] [Pitch] Support for pure functions. Part n + 1.

[Michel Fortin]

Le 20 févr. 2017 à 1:19, David Sweeris <davesweeris at mac.com> a écrit :
> 
> On Feb 19, 2017, at 21:19, Xiaodi Wu <xiaodi.wu at 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