Rob Jacques <sandf...@jhu.edu> changed:
What |Removed |Added
--- 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 (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?
>  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: -------