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