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
