> On Feb 16, 2017, at 9:51 AM, Robert Widmann via swift-evolution > <[email protected]> wrote: > > > >> On Feb 16, 2017, at 12:30 PM, Rien via swift-evolution >> <[email protected]> wrote: >> >> In essence this is about assistance from the compiler that a function marked >> ‘pure’ is indeed pure? >> I.e. an error message should be generated when a function marked as ‘pure’ >> is in fact not ‘pure’? >> >> If the answer to both questions is ‘yes’ then -not surprising- its a -1 from >> me. >> >> Unless there are other benefits? > > This feature already exists in a certain sense - via the @effects annotation > - but is undocumented, highly unstable, and does not entail any semantic > checking. I think that at least indicates a desire, even if it’s only in the > lower-level parts of SIL now, to have some way to determine the “purity” of a > function to perhaps guide an inliner or future block fusion pass. Perhaps > Andrew Trick can speak more about the goals of the annotation and whether it > would be ready for prime time as it were.
Effects is too low-level to be useful for much user code. It blindly applies LLVM attributes that are difficult for most Swift code to live up to. Any value type with refcounted fields immediately fails the "readnone" test even if it's semantically pure at the value semantics abstraction level. I think a higher-level 'pure' annotation like TJ is proposing, which fits into the value semantics model, is more useful as a user-facing feature, both as a reasoning tool and as an enabler for higher-level optimization. -Joe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
