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. artur
