On Thu, 07 Jun 2012 11:55:32 -0400, Artur Skawina <[email protected]>
wrote:
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?
I contend it would make marking a template as pure more useful -- you can
with one keyword ban all use of shared via template parameters on a
template function, given that it does not properly protect shared data
from races. You can do the same with template constraints, but it's
unnecessary boilerplate, only there because the compiler incorrectly
allows PAS functions. Unless you plan to implement a shared version, in
which case there's no less or more code.
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?
To what improvements do you refer? I think what is currently in place is
sound design, with incomplete or buggy implementation.
-Steve
