> On Aug 18, 2017, at 2:45 PM, David Sweeris via swift-evolution
> <[email protected]> wrote:
>
> If we define our semantics carefully enough, could we realistically make it
> so that "@pure" or "@impure" (or whatever) would simply be a note to the
> compiler, letting it skip that bit of analysis for the function in question?
>
>
>
>> The secondary concern is that you need to build out the model enough that
>> you don’t prevent abstractions. A pure function should be able to create an
>> instance of a struct, mutate it (i.e. calling non-pure functions) etc. This
>> requires a non-trivial design, and as the design complexity creeps, you run
>> the risk of it getting out of control.
>
> Did we ever get around to figuring which definition(s) of "pure" that we
> wanted to support, or did the discussion always get out of scope before we
> got that far? I know the issue's been brought up, but I don't recall if it
> was discussed enough to reach any conclusions.
It became clear that we weren’t going to change Swift’s default semantics in
the version 2/3 timeframe, and we made the effort to do sufficient whole-module
analysis to make up for it. I see this primarily being a resilience issue in
the future. Eventually I think we’ll want public APIs to be able to declare
some level of statically enforced purity. We might even get some level of
default guarantee as a way of “deprecating global var”. But that whole
discussion has rightly been punted.
-Andy
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
