www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7312] New: const should be abstract

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7312

           Summary: const should be abstract
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: timon.gehr gmx.ch


--- Comment #0 from timon.gehr gmx.ch 2012-01-18 11:03:10 PST ---
const only has a meaning in presence of aliasing. Unique const data is
meaningless. const is abstract. strongly pure functions should not be allowed
to return const; they can return mutable or immutable data instead.

static assert(!is(typeof(new const(Object))));
static assert(!is(typeof(new const(int)[1])));
static assert(!is(typeof({const(Object) foo(){return new Object;}})));
static assert(!is(typeof({const(int)[] foo(){return new int[1];}})));

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 18 2012
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7312


Jonathan M Davis <jmdavisProg gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg gmx.com


--- Comment #1 from Jonathan M Davis <jmdavisProg gmx.com> 2012-01-18 13:55:00
PST ---
I can see why it would be considered bad practice to return const from a
strongly pure function, but why should it be disallowed by the compiler?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7312


timon.gehr gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3


--- Comment #2 from timon.gehr gmx.ch 2012-01-18 14:25:22 PST ---
Immutable has all the constraints const has and gives actual guarantees. I
don't think it is very important to enforce it, but it would be a net gain.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 18 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7312


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au


--- Comment #3 from Don <clugdbug yahoo.com.au> 2012-06-27 00:06:13 PDT ---
It is currently possible to declare 'const int' variables even though they are
identical to 'immutable int' ones. This is similar.

And consider:

const[] foo(S y) pure { ... }

With this proposal, that's OK for struct S, as long as the struct has a
pointer.
But if S has no pointers, the return value needs to be immutable.
That's just annoying.

This proposal doesn't add any value.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2012
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7312


timon.gehr gmx.ch changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


--- Comment #4 from timon.gehr gmx.ch 2012-06-27 04:40:06 PDT ---
agreed.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 27 2012