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

[David Sweeris]

> On Feb 19, 2017, at 11:47, Michel Fortin via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 7. Is it desirable that the optimizer sometime take the pure attribute to heart to combine multiple apparently redundant calls into a single one? Or is pure not intended to be usable for compiler optimizations? The ability to optimize will likely be affected by the answer to these question and the loopholes you are willing to allow.

AFAIK, "compiler optimizations" are main point of having a keyword for pure functions. (Well, that and whatever role it might play in supporting constant expressions, but that seems like more of a compiler implementation detail than an actual "feature" of pure functions.)

Calling fatalError() is fine IMHO because, at that point, any side-effects become a moot point.

I'm inclined to say that passing in reference values is ok, as long as we can prove the function doesn't modify anything. Don't know how we'd do that, though, since classes don't need that `mutating` keyword for functions that mutate `self`.

If someone is determined to use pointers to pointers to get global state or something to trick the compiler into accepting semantically impure code as syntactically pure, I'm not sure there's a way we can really stop them. Not and still have @pure be useful. (Or maybe we can... I'm merely thinking of the saying, "every time someone builds a fool-proof system, the world makes a bigger fool".)

I would think that allocating memory is ok, as long as it's either deallocated by the time the function exits or it's part of the return value, but I don't know a lot about low-level implementation details, so maybe there's something I'm missing. If that is a problem, though, I think the answer to your "what subset..." question would, more or less, be whatever subset doesn't rely on the runtime (the usefulness of that subset should expand if/when we extend the syntax around tuples or support fixed-length arrays in some other way).

In any case, yeah, IMHO you're correct that we should nail down the semantics before worrying so much about the syntax.

- Dave Sweeris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170219/08330be7/attachment.html>