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

           Summary: Mutable references to const/immutable/shared classes
           Product: D
           Version: D2
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: michel.fortin@michelf.com


--- Comment #0 from Michel Fortin <michel.fortin@michelf.com> 2010-12-05 17:40:02 EST ---
Created an attachment (id=840)
Enable const(Object)ref syntax and semantics (patch)

It is currently not possible in the type system to have a mutable reference to a const/immutable/shared/inout class, the reference always has the same modifiers as the class itself. This is suboptimal as it prevents generic algorithms from treating classes like other types.

This proposal extends type expressions so you can optionally make the references part of a class variable explicit:

    Object a = new Object;
    Object ref b = new Object; // same thing

This then allows modifiers to be applied separately to the reference as needed:

    const(Object)ref c = new Object;
    shared(const(Object)ref) d = new Object;
    shared(Object ref) d = new Object; // same as shared(Object)

Type Matching
-------------
Using type matching to remove the qualifiers will now remove qualifiers only on the reference part, similar to what would happen with pointers. There's not way to remove the qualifier on the class part currently. This affects the behaviour of Phobos's Unqual template when used with class.

Mangling
--------
Object type mangling stays unchanged when the reference has the same modifiers as the class itself. When the reference has a different modifiers than the reference, the reference is added before the class as a 'X' prefixed with the type modifiers. For instance: "xXyC6Object" denotes a const ('x') reference to an immutable ('y') class.

TypeInfo
--------
Type modifiers for the reference are not reflected in TypeInfo. Perhaps this should be added.

Attached is a patch to enable this based on DMD revision 780. Also, once this path is applied, one trivial change is needed in Phobos to fix Rebindable's unittest (ironic!). All other tests are passing.

-- 
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=5325


Michel Fortin <michel.fortin@michelf.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
    Attachment #840|application/octet-stream    |text/plain
          mime type|                            |
 Attachment #840 is|0                           |1
              patch|                            |


-- 
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=5325



--- Comment #1 from Michel Fortin <michel.fortin@michelf.com> 2011-02-07 19:28:16 EST ---
New patch submitted as a github pull request: https://github.com/D-Programming-Language/dmd/pull/3

-- 
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=5325


Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu


--- Comment #2 from Martin Nowak <code@dawg.eu> 2013-07-24 05:07:31 PDT ---
How about making a distinction between const(Object) and const Object?
I think it would be less intrusive and more in line with the const(void)* vs.
const void* behavior.

-- 
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=5325



--- Comment #3 from Michel Fortin <michel.fortin@michelf.com> 2013-07-24 08:22:53 EDT ---
(In reply to comment #2)
> How about making a distinction between const(Object) and const Object?
> I think it would be less intrusive and more in line with the const(void)* vs.
> const void* behavior.

That'll only work in the context where you're declaring a tail-const variable of type Object. If you're declaring an array of tail-const objects, or passing a tail-const object as a template parameter, you can't omit the parenthesis. But the ref postfix works:

   const(Object)ref[] arrayOfTailConstObjects;

-- 
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=5325


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra@gmail.com


--- Comment #4 from monarchdodra@gmail.com 2013-07-24 08:07:04 PDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > How about making a distinction between const(Object) and const Object?
> > I think it would be less intrusive and more in line with the const(void)* vs.
> > const void* behavior.
> 
> That'll only work in the context where you're declaring a tail-const variable of type Object. If you're declaring an array of tail-const objects, or passing a tail-const object as a template parameter, you can't omit the parenthesis. But the ref postfix works:
> 
>    const(Object)ref[] arrayOfTailConstObjects;

Note that you can use std.typecons.Rebindable to achieve what you are doing:
Rebindable!C //Creates a simple an alias to C
Rebindable!(immutable C) Creates a mutable object that holds an immutable C.
Rebindable!(const C) Creates a mutable object that can hold any reference to C.

The thing is very light weight, so in theory, you can use it, and you should have 0 overhead (in release)... Well, except if you use it inside algorithms like emplace/array or whatnot, as they'll notice an elaborate opAssign, and take a slower road.

It is, of course, pure and nothrow, but apparently, it is not @safe/@trusted, but I don't see why... It should. I'll make a mental note to do it.

Unfortunately, it requires an import, and looks like ass. But it's your current workaround. wish we had something simpler and more idomatic, but that's they way it is. How does C# deal with this?

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