should pure functions accept/deal with shared data?

[Jonathan M Davis]

On Thursday, June 07, 2012 10:43:04 Steven Schveighoffer wrote:
> On Wed, 06 Jun 2012 19:01:59 -0400, Alex Rønne Petersen <alex at lycus.org>
> 
> wrote:
> > Steven, in your particular case, I don't agree entirely. The operation
> > can be atomic quite trivially by implementing inc() like so (for the
> > shared int case):
> > 
> > void inc(ref shared int i) pure nothrow
> > {
> > 
> > // just pretend the compiler emitted this
> > asm
> > {
> > 
> > mov EDX, i;
> > lock;
> > inc [EDX];
> > 
> > }
> > 
> > }
> > 
> > But I may be misunderstanding you.
> 
> I think you are. 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!)

But what does it matter if a PAS function can be called from a strongly pure 
function? If it can't be called from a strongly pure function anyway, then you 
don't have to worry about shared being used in a strongly pure function 
regardless of whether pure is permitted in weakly pure functions.

However, if shared is banned from pure functions, then you can't mark any 
function which would otherwise be pure as pure. As it stands, you can have

auto func(T)(T stuff) pure {}

where if you pass it non-shared, it can be used in a strongly pure function 
with all of its benefits, _and_ you can call it with shared (in which case, it 
can't be called in a strongly pure function, but that doesn't mean that 
function isn't useful). If shared were not permitted in pure functions, then 
you'd have to do

auto func(T)(T stuff) {}

in which case, func could be used with impure, non-shared stuff, which the 
previous signature prevented. To avoid that, you have to duplicate the 
function - one version for shared and one without.

In addition, if you have a PAS function, it has the guarantee that it won't 
access anything mutable that wasn't passed to it. If you make PAS illegal, 
then there is _no_ way to have that guarantee for shared.

I don't see how allowing shared in pure functions costs us _anything_. No, 
such a function can't be used in a strongly pure function, but you still have 
the guarantee about mutable globals (which is definitely worth something), and 
you avoid having to duplicate the function for shared vs non-shared. And since 
it _can't_ be called from a strongly pure function, you don't have to worry 
about the fact that multiple calls to such a function can result in different 
return values due to another thread altering the variable.

As far as I can tell, making PAS functions illegal just makes life harder and 
buys us nothing. Strongly pure is where the optimization benefits of shared 
are, and PAS functions don't prevent that at all - they just can't gain from 
it.

It seems like your issue with PAS stems primarily from the idea that such a 
weakly pure function can't be called from a strongly pure function, and I 
don't see why that's really a problem - particularly given that that's not 
pure's only benefit and is arguably the _smaller_ of its benefits given how 
rarely it can actually be applied.

- Jonathan M Davis