should pure functions accept/deal with shared data?

[Artur Skawina]

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