> On Feb 19, 2017, at 11:47, Michel Fortin via swift-evolution
> <swift-evolution@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution