[Issue 1983] New: Big Hole in Const System

[Issue 1983] Delegates violate const

Jan 30, 2012

yebblies

Jun 04, 2013

Kenji Hara

Jun 04, 2013

David Nadlinger

Jun 04, 2013

github-bugzilla@puremagic.com

Jul 26, 2013

Kenji Hara

http://d.puremagic.com/issues/show_bug.cgi?id=1983 Summary: Big Hole in Const System Product: D Version: 2.012 Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: bugzilla@digitalmars.com ReportedBy: caron800@googlemail.com There appears to be a large hole in the const system, demonstrated by the following code. import std.stdio; class A { private int x_ = 1; void x(int n) { x_ = n; } int x() const { return x_; } } void main() { const(A) a = new A; // The following correctly won't compile // a.x = 2; // a.x(2); // **** BUT THIS WILL **** (&a.x)(2); writefln(a.x); // writes 2 } The problem is that the expression (&a.x) has type void delegate(int x) wheras it /should/ have type void delegate(int x) const Unfortunately, there is no way to declare a const delegate (by which I mean, a delegate whose context pointer is typed const). I see this as a big problem. Without the ability to specify the constancy of delegate contexts, it will be impossible to declare pure delegates. (If we ever get parallel foreach, we're going to need pure delegates). --

http://d.puremagic.com/issues/show_bug.cgi?id=1983 fvbommel@wxs.nl changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |accepts-invalid OS/Version|Windows |All ------- Comment #1 from fvbommel@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. Creating a delegate to a non-const member function of a const object should be a compile-time error. --

> ------- Comment #1 from fvbommel@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/. 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 Janice

Janice Caron wrote: >> ------- Comment #1 from fvbommel@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.

http://d.puremagic.com/issues/show_bug.cgi?id=1983 Don <clugdbug@yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug@yahoo.com.au --- Comment #4 from Don <clugdbug@yahoo.com.au> 2011-03-18 23:36:27 PDT --- Bug 3656 seems to be another example of this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1983 Kenji Hara <k.hara.pg@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |k.hara.pg@gmail.com --- Comment #5 from Kenji Hara <k.hara.pg@gmail.com> 2011-05-18 07:23:31 PDT --- Posted patches: https://github.com/D-Programming-Language/dmd/pull/70 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

June 06, 2011

[Issue 1983] Big Hole in Const System

Posted by Rob Jacques
in reply to d-bugmail

Permalink

Rob Jacques

Posted in reply to d-bugmail

Permalink

http://d.puremagic.com/issues/show_bug.cgi?id=1983


Rob Jacques <sandford@jhu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sandford@jhu.edu


--- Comment #6 from Rob Jacques <sandford@jhu.edu> 2011-06-06 12:42:15 PDT ---
(In reply to comment #3)
> Janice Caron wrote:
> >>  ------- Comment #1 from fvbommel@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: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1983 yebblies <yebblies@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch CC| |yebblies@gmail.com --- Comment #7 from yebblies <yebblies@gmail.com> 2011-06-08 22:18:25 PDT --- https://github.com/D-Programming-Language/dmd/pull/71 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=1983 Steven Schveighoffer <schveiguy@yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schveiguy@yahoo.com --- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> 2011-06-12 11:28:15 PDT --- *** Issue 3656 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------

Forums