www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 5325] New: Mutable references to const/immutable/shared classes

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



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: -------
Dec 05 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5325


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

           What    |Removed                     |Added
----------------------------------------------------------------------------

          mime type|                            |

              patch|                            |


-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 05 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5325




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: -------
Feb 07 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5325


Martin Nowak <code dawg.eu> changed:

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



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: -------
Jul 24 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5325




08:22:53 EDT ---


 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: -------
Jul 24 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=5325


monarchdodra gmail.com changed:

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







 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


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