On 18/06/12 17:00, Artur Skawina wrote:
On 06/18/12 16:41, deadalnix wrote:
Le 18/06/2012 16:28, Artur Skawina a écrit :
It's fine, if you view a delegate as opaque.
No it isn't. You cannot ensure transitivity anywhere. This have obvious, and
severe drawback for concurrent programing (implicit sharing is back) and GC
performances (GC can eb crazy fast when it come to transitive immutable data,
see OCaml's GC performances for instance).
'this' being const does not preclude accessing the object that 'this'
points to via another, mutable, reference.
Consider the alternative - you'd have to forbid storing any delegate
with a non-const non-value argument inside any object.
So how would you like to handle this? And, no, allowing only the cases
that /can/ be statically checked is not ok - it would result in black
magic - delegates would be accepted or not depending on the contents
of the object (think templates and composition).
And "breaking" const would then _still_ be possible and trivial.
No, and your example don't demonstrate that in any way. Transitivity is
maintained in the example below, because g isn't a member of s, and if it were,
then the example would break at compile time.
The word "breaking" is in quotes for a reason. Const is not an immutability
guarantee. If you treat delegates as opaque then there's no practical
difference between using them or accessing the data via another external
reference.
purity is another beast altogether.
D's "weak pure" can help; I just don't like the redefinition of the term
"purity"; another name for "weak purity" would be better.
So would I. Can you think of one?
It was the best name I could come up with, given that the 'pure' was the
keyword.
We want a word that means 'no hidden state'.
