I'm going to update the draft with points addressed here and the twitter conversation. There have been quite a few implications to consider pointed out.
This feature is not 'for' the compiler as much as it is for humans writing code, but I will address that in the update. On Sun, Feb 19, 2017 at 3:34 PM, David Sweeris <[email protected]> wrote: > > On Feb 19, 2017, at 11:47, Michel Fortin via swift-evolution < > [email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
