> On Feb 20, 2017, at 2:56 PM, David Sweeris via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Feb 20, 2017, at 2:50 PM, Michel Fortin via swift-evolution
>> <[email protected]> wrote:
>>
>>> Le 20 févr. 2017 à 14:45, Matthew Johnson <[email protected]> a écrit :
>>>
>>>>
>>>> On Feb 20, 2017, at 1:42 PM, Michel Fortin <[email protected]>
>>>> wrote:
>>>>
>>>>> Le 20 févr. 2017 à 14:23, Charles Srstka <[email protected]> a
>>>>> écrit :
>>>>>
>>>>> I’m not sure how I feel about that, since it hamstrings the ability to
>>>>> improve APIs in a lot of ways without breaking backwards compatibility. A
>>>>> quick example off the top of my head would be all the Cocoa APIs that
>>>>> started out having ivars representing paths backed by simple getter
>>>>> methods, and were later refactored to be URL-based, but with the original
>>>>> path properties become computed properties pointing to the URL’s “path”
>>>>> property. With this, properties would not be able to be refactored in
>>>>> this way unless the library developer had previously declared the “path”
>>>>> property as private(set), which is unlikely for a property that was not
>>>>> intended to be changed after the class was initialized.
>>>>
>>>> Version 1:
>>>>
>>>> public class A {
>>>> public let path: String
>>>> }
>>>>
>>>> Version 2:
>>>>
>>>> public class A {
>>>> public pure var path: String { return url.path }
>>>> public let path: URL
>>>> }
>>>>
>>>> This is assuming `let` is implicitly pure. It probably should not be. Or
>>>> at least it should not when crossing module boundaries. Note that internal
>>>> to the module it wouldn't violate any contract to allow pure code access
>>>> to `let` variables.
>>>>
>>>> Which makes me think of an idea: internal to the module, `pure` could be
>>>> inferred for everything. Only the published APIs would require the
>>>> annotations, and only if you want `pure` to be part of the API contract.
>>>> Attaching `pure` to an internal function could still be useful for your
>>>> own reasoning though.
>>>
>>> That’s a very interesting approach that could lighten the syntactic load.
>>> We could strategically annotate our code where we want purity verified, but
>>> otherwise omit the annotation for members that don’t need to be visible
>>> outside the module. This approach works especially well for closures. I
>>> like it a lot!
>>
>> There is an important limitation to this though: a class method that mutate
>> something in the class is never going to be implicitly pure (per the rules
>> of purity for instance methods). For that the compiler would have to prove
>> the method is only called from unique references, and that'd be a bit weird
>> (add a method call somewhere and suddenly the function becomes impure).
>>
>> There's also an issue with diagnostics: say you have func1 that calls func2
>> that calls func3. Func1 is `pure`, the other two are pure only implicitly.
>> Then you change something in func3, and suddenly func1 complains that it
>> can't call impure func2 and you are left wondering why because you haven't
>> changed anything in func2. Perhaps the compiler could dig in the call tree
>> to find the impure operation and tell you, but that's starting to look like
>> the awful diagnostic messages for C++ templates.
>
> Could we only infer purity for one “level”? As a technical limitation rather
> than part of the language spec, to be removed at some later date when we have
> time to implement the diagnostic logic? So in your example, the purity of
> func2 or func3 could be inferred, but the other would have to be annotated.
>
> - Dave Sweeris
It seems like there's a parallel to 'throws' here, where the unknown
throwy-ness of a function has to be dealt with for closures with 'rethrows'.
Pie in the sky, perhaps, but it'd be interesting to see what a generalized
effects system would look like for Swift, ideally subsuming both of those and
allowing for many others.
David
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
