http://d.puremagic.com/issues/show_bug.cgi?id=1983
Rob Jacques <sandf...@jhu.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sandf...@jhu.edu --- Comment #6 from Rob Jacques <sandf...@jhu.edu> 2011-06-06 12:42:15 PDT --- (In reply to comment #3) > Janice Caron wrote: > >> ------- Comment #1 from fvbom...@wxs.nl 2008-04-10 05:55 ------- > >> IMHO the problem here isn't the type of (&a.x) but the fact that it's > >> allowed > >> to compile at all. > > > > Same thing. You just stated the problem differently. > > > > a.x = 2; > > > > won't compile because a.x is typed const. Wheras > > > > (&a.x)(2); > > > > will compile because (&a.x) is not typed const. The fact that it > > compiles is a /symptom/. > > I disagree. As long as (&a.x) for mutable a and const x (and similar > cases with invariant, etc.) doesn't compile, there's no need for > 'delegate() const'. See below. > > > We can treat the symptom, but I'd rather > > treat the disease. To treat the disease, the type system must allow > > types such as > > > > ReturnType delegate(Params...) const > > > > to exist. Likewise > > > > ReturnType delegate(Params...) invariant > > > > and eventually, we're even going to need > > > > ReturnType delegate(Params...) invariant pure > > I can see the need for the pure variant, but not any of the others. I > see no reason to distinguish between a delegate to a const method and > one to a normal method, as long as you can't create a delegate to a > method using an object of inappropriate constness. > Who (except again in case of 'pure') cares if the object pointed to by > the void* .ptr changes if the method is called? Obviously whoever > created the delegate must have had mutable access to it[1] (since that > should IMHO be the only way to create such a delegate), so they have > every right to create a delegate that mutates it. > > In other words: since you don't have a useful explicit reference to the > object, who cares if it's const or not? > > > [1] Or invoked undefined behavior by somehow casting away const, in > which case it doesn't matter *what* happens. const delegates are extremely important to parallelism and concurrency, i.e. the routines in std.parallelism. This is because calling a const delegate from multiple threads is _safe_, given guarantees that mutating members/delegates won't be called until after synchronization barriers. (i.e. using const delegates provides race-safety to parallel foreach, reduce, etc.) (Well, except for the corner case of accessing a global shared variable) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------