www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2625] New: Inconsistent behavior with const/immutable struct members

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

           Summary: Inconsistent behavior with const/immutable struct
                    members
           Product: D
           Version: 2.023
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: dsimcha yahoo.com


struct Pair {
    immutable uint g1;
    uint g2;
}

void main() {
    works();
    broken();
}

void works() {
    Pair[1] stuff;
    stuff[0] = Pair(1, 2);  // Modify immutable by rebinding whole struct.
}

void broken() {
    Pair stuff;
    stuff = Pair(1, 2);  // Error:  test.broken.stuff cannot modify struct with
immutable members
}

I'm honestly not sure which of these represents truly correct behavior.  This
will take some debate and/or a language lawyer to resolve.  If you interpret
the statement someVar = Pair(num1, num2); as a rebinding operation, similar to
rebinding class references, then the behavior in works() is correct.  If you
believe that the struct case is fundamentally different because structs are
value types, then the behavior in broken() may be correct.  However, either way
the behavior should be consistent and should not depend on whether you're
modifying a stack variable or an array element.


-- 
Jan 27 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2625


dsimcha yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
           Keywords|spec                        |accepts-invalid
            Summary|Inconsistent behavior with  |Creating new struct with
                   |const/immutable struct      |literal bypasses
                   |members                     |immutability of members if
                   |                            |struct is in array




------- Comment #1 from dsimcha yahoo.com  2009-04-01 15:06 -------
Upon thinking about this some more, it's pretty clear that one should *not* be
able to change the value in an existing memory location by creating a whole new
struct, i.e. the following is bad:

struct Pair {
    immutable uint g1;
    uint g2;
}

void main() {
    Pair[1] stuff;
    stuff[0] = Pair(1, 2);  // Modify immutable by rebinding whole struct.
}

Note that the same thing happens if stuff is a dynamic array instead of a
static array.  Upping severity, giving more descriptive title.


-- 
Apr 01 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2625


maxmo pochta.ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |2573
              nThis|                            |




------- Comment #2 from maxmo pochta.ru  2009-04-02 07:02 -------
According to specs http://digitalmars.com/d/2.0/struct.html works() is correct.
I think, broken() is correct, since invariant data can be referenced directly,
so it's incorrect for it to change in time.


-- 
Apr 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2625


smjg iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg iname.com




------- Comment #3 from smjg iname.com  2009-04-02 13:12 -------
(In reply to comment #2)
 According to specs http://digitalmars.com/d/2.0/struct.html works() is correct.

Where on that page is the issue addressed?
 I think, broken() is correct, since invariant data can be referenced directly,
 so it's incorrect for it to change in time.

I'm a little puzzled by your use of "correct". By my calculation, both are incorrect - the difference is whether the compiler correctly diagnoses this fact. It makes no sense to reassign a struct that has immutable members by any means. In fact, a struct with at least one immutable member should be treated as itself immutable for most purposes. I'll look into it a bit more when I've time.... --
Apr 02 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2625





------- Comment #4 from smjg iname.com  2009-04-03 09:09 -------
Here's how it would have to work.

Really, there are four constancy levels:
- reassignable (the default)
- mutable but non-reassignable (MBNR)
- const
- invariant (immutable)

For primitive types and static arrays thereof, only two of these are distinct:
reassignable and invariant.  If something of such a type is declared const, it
actually becomes invariant.

The constancy of a struct is determined by two factors: the constancy of its
members and any constancy attributes with which the struct as a whole is
declared.

The constancy of a struct as determined by its members works like this:
- if all members are reassignable, it is reassignable
- if all members are invariant, it is invariant
- if all members are const, or all members are const or invariant, it is const
- otherwise, it is MBNR

The otherwise is if the struct has a mixture of reassignable and const and/or
invariant members, or has any MBNR members.  Or equivalently, if struct members
of structs are flattened out, the overall struct is MBNR iff there is a mixture
of reassignable and const and/or invariant members.

The essence of MBNR is that the struct cannot be reassigned, but the constancy
levels of the struct's members shine through.

Of course, it would still be possible to declare a struct 'variable' as const
or invariant, and this would be a matter of tightening the constancy from that
which is in the type.


-- 
Apr 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2625


maxmo pochta.ru changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://digitalmars.com/d/2.0
                   |                            |/struct.html
           Keywords|                            |spec




------- Comment #5 from maxmo pochta.ru  2009-04-04 08:19 -------
(In reply to comment #3)
 Where on that page is the issue addressed?

 I think, broken() is correct, since invariant data can be referenced directly,
 so it's incorrect for it to change in time.

I'm a little puzzled by your use of "correct".

--
Apr 04 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2625





------- Comment #6 from smjg iname.com  2009-04-04 08:51 -------
(In reply to comment #5)
 (In reply to comment #3)
 Where on that page is the issue addressed?

see "Const and Invariant Structs"

That bit talks about the whole struct being declared const. But you're right, it doesn't seem to make sense. It would appear that that section had been blindly c&p'd from the page about classes, except that that page now doesn't go into as much detail on this matter.
 I think, broken() is correct, since invariant data can be 
 referenced directly, so it's incorrect for it to change in time.

I'm a little puzzled by your use of "correct".

I meant, it's correct that error is given for broken().

To me, that's the compiler being correct - quite a different thing from the code being correct. --
Apr 04 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2625





------- Comment #7 from maxmo pochta.ru  2009-04-04 09:16 -------
(In reply to comment #6)
 That bit talks about the whole struct being declared const.

it talks about members too.
 I meant, it's correct that error is given for broken().

To me, that's the compiler being correct - quite a different thing from the code being correct.

both functions have the same code. --
Apr 04 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2625





------- Comment #8 from smjg iname.com  2009-04-19 07:59 -------
(In reply to comment #7)
 To me, that's the compiler being correct - quite a different thing from the
 code being correct.

both functions have the same code.

That depends on whether you mean source code or object code. I was thinking about source code when I made that statement. --
Apr 19 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2625



--- Comment #9 from Stewart Gordon <smjg iname.com> 2010-12-07 04:08:05 PST ---
A similar problem has just cropped up as issue 5327.

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