On 06/07/12 16:43, Steven Schveighoffer wrote: > I understand the implementation is not correct for shared, and that actually > is my point. The current compiler lets you do the wrong thing without > complaint. Given that the shared version of the function needs to be written > differently than the unshared version, we gain nothing but bugs by allowing > pure functions that operate on shared. > > In essence, a pure-accepting-shared (PAS) function is not realistically > useful from a strong-pure function. A strong-pure function will have no ties > to shared data, and while it may be able to create data that could > potentially be shared, it can't actually share it! So a PAS function being > called from a strong-pure function is essentially doing extra work (even if > it's not implemented, the expectation is it will be some day) for no reason. > > So since a PAS function cannot usefully be optimized (much better to write an > unshared version, it's more accurate), and must be written separately from > the unshared version, I see no good reason to allow shared in pure functions > ever. I think we gain a lot by not allowing it (more sanity for one thing!)
While it's true that "shared" inside pure functions doesn't _look_ right, can you think of a case where it is actually wrong, given the pure model currently in use? Would inferring templated functions as impure if they access (and not just reference) shared data help? IOW, a function marked as pure that deals with shared data can not be "truly" pure, and can not be called from a "really" pure function (as that one would have to handle shared, so it couldn't be pure either) - so does it make sense to add new restrictions now, and not delay this until the "pure" model is improved? artur
