should pure functions accept/deal with shared data?

[Artur Skawina]

On 06/08/12 09:00, dennis luehring wrote:
>>>> >>We clearly agree completely; this is exactly what I'm saying in the paragraph you
>>>> >>quoted below. What i'm*also*  saying is that the 'incorrectness' of it is harmless
>>>> >>in practice - so I'm not sure that it should be forbidden, and handled specially
>>>> >>(which would be necessary in the inferred-purity cases).
> 
> but it makes no sense to cripple an feature like pure half-way - pure is clean and well defined (still not perfect) - but you talking about making it very stupid and sensless "'incorrectness' of it is harmless
> in practice" ...

Marking a function that takes a pointer or reference which is not immutable does *not*
make it pure, it only allows it to be called from another pure function, that's all.
That's how D implements purity - if you think that's wrong and/or misleading, I agree,
but that's how it is.
'int f(shared T*)' can be tagged as pure, but can *never* actually be pure, because its
caller can never be pure. That's why allowing it to be "pure" is harmless, even if it
looks "incorrect" to have pure functions dealing with shared. It's a consequence of D's
current purity model, and, yes, it is confusing.

> "Yes, they can be used incorrectly, but I'd expect anybody working with shared to know what they're doing" - no they don't - sorry, haven't you any real experience in the threading world or why don't you see the problems introdcing shared in pure

The only way to (relatively) safely deal with raw (ie builtin) shared types it to
treat 'shared' as the D equivalent of C's 'volatile'. Anything else won't correctly,
and, no, it can't be made to work, attempting that would make 'shared' even less
useful.

Shared data in pure code makes no sense, yes. D's "pure" is not the same as sanely
defined "pure", however.

artur