www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1983] New: Big Hole in Const System

reply d-bugmail puremagic.com writes:
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).


-- 
Apr 10 2008
next sibling parent reply d-bugmail puremagic.com writes:
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.


-- 
Apr 10 2008
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
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.
Apr 11 2008
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
  ------- 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
Apr 10 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 18 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
May 18 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 06 2011
prev sibling parent d-bugmail puremagic.com writes:
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: -------
Jun 08 2011