[swift-evolution] [Proposal idea] Support for pure functions
davesweeris at mac.com
davesweeris at mac.com
Thu Jan 14 18:07:59 CST 2016
Pure functions, as a concept, get +3245 from because, among other reasons, I *think* it’d help with auto-parallelization, which is of course the greatest computational problem of our time (besides a lack of native CPU support for arbitrary precision math). If not, then merely +1… I simply do not believe it wouldn’t eventually be useful for something (manual parallelization comes to mind), and the sooner we get language support for deep concepts like this, the less code will have to be recompiled if it breaks something (and somehow gets accepted anyway).
At the moment, the only other strong opinion I have on the matter is that only going with “auto-detect” is a bad idea, because then there’s no clear way to tell why you can’t pass your “I-thought-it-was-pure-but-it-really-isn’t” function to something that requires a function that actually is pure. I don’t mind the compiler auto-detecting purity (or anything, really) in addition to manual annotations, if it can, but I’ll always want a way to override it.
- Dave Sweeris
> On Jan 14, 2016, at 04:22, Michel Fortin via swift-evolution <swift-evolution at swift.org> wrote:
>
> In D, for template functions, the pure attribute is deduced from the function's body. It'd be nice to have deduced purity so you don't have to figure out those conditional purity requirements for every function.
>
> Deduced purity should probably not extend automatically to other resilience domains though, because it provides a guaranty that might not apply to future versions of that function. So you still need a way to annotate.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160114/0983bd38/attachment.html>
More information about the swift-evolution
mailing list