Why does isMutable and isAssignable return true for a struct/class that are immutable?

immutable struct A { }

isMutable!A returns true.

On Monday, 15 July 2013 at 14:50:04 UTC, JS wrote:
> Why does isMutable and isAssignable return true for a struct/class that are immutable?
>
> immutable struct A { }
>
> isMutable!A returns true.

looks like

immutable struct A
{
    int a;
}

acts as a

struct A
{
    immutable:
        int a;
}

Now, I don't see this use case (qualified aggregate definition) anywhere in spec and this may be intended behavior. But I do agree this looks misleading.

On Monday, 15 July 2013 at 15:08:58 UTC, Dicebot wrote:
> On Monday, 15 July 2013 at 14:50:04 UTC, JS wrote:
>> Why does isMutable and isAssignable return true for a struct/class that are immutable?
>>
>> immutable struct A { }
>>
>> isMutable!A returns true.
>
> looks like
>
> immutable struct A
> {
>     int a;
> }
>
> acts as a
>
> struct A
> {
>     immutable:
>         int a;
> }
>
> Now, I don't see this use case (qualified aggregate definition) anywhere in spec and this may be intended behavior. But I do agree this looks misleading.

Yes, I need immutable to do what it does but also need a way to emulate an enum.

This is because I need to constrain my templates properly. If struct A isn't immutable then it is no different than any other struct which is bad because I want only enum like structs.

maybe immutable immutable(struct) A would be a good way to specify this.

An immutable struct should be similar to an enum... a purely compile time construct not meant to be instantiated in any way.

On Monday, 15 July 2013 at 15:59:44 UTC, JS wrote:
> On Monday, 15 July 2013 at 15:08:58 UTC, Dicebot wrote:
>> On Monday, 15 July 2013 at 14:50:04 UTC, JS wrote:
>>> Why does isMutable and isAssignable return true for a struct/class that are immutable?
>>>
>>> immutable struct A { }
>>>
>>> isMutable!A returns true.
>>
>> looks like
>>
>> immutable struct A
>> {
>>    int a;
>> }
>>
>> acts as a
>>
>> struct A
>> {
>>    immutable:
>>        int a;
>> }
>>
>> Now, I don't see this use case (qualified aggregate definition) anywhere in spec and this may be intended behavior. But I do agree this looks misleading.
>
> Yes, I need immutable to do what it does but also need a way to emulate an enum.
>
> This is because I need to constrain my templates properly. If struct A isn't immutable then it is no different than any other struct which is bad because I want only enum like structs.
>
> maybe immutable immutable(struct) A would be a good way to specify this.
>
> An immutable struct should be similar to an enum... a purely compile time construct not meant to be instantiated in any way.

Why is it you're trying to emulate an enum? Perhaps there's a way to achieve what you want by more normal means.

On Monday, 15 July 2013 at 16:17:02 UTC, John Colvin wrote:
> On Monday, 15 July 2013 at 15:59:44 UTC, JS wrote:
>> On Monday, 15 July 2013 at 15:08:58 UTC, Dicebot wrote:
>>> On Monday, 15 July 2013 at 14:50:04 UTC, JS wrote:
>>>> Why does isMutable and isAssignable return true for a struct/class that are immutable?
>>>>
>>>> immutable struct A { }
>>>>
>>>> isMutable!A returns true.
>>>
>>> looks like
>>>
>>> immutable struct A
>>> {
>>>   int a;
>>> }
>>>
>>> acts as a
>>>
>>> struct A
>>> {
>>>   immutable:
>>>       int a;
>>> }
>>>
>>> Now, I don't see this use case (qualified aggregate definition) anywhere in spec and this may be intended behavior. But I do agree this looks misleading.
>>
>> Yes, I need immutable to do what it does but also need a way to emulate an enum.
>>
>> This is because I need to constrain my templates properly. If struct A isn't immutable then it is no different than any other struct which is bad because I want only enum like structs.
>>
>> maybe immutable immutable(struct) A would be a good way to specify this.
>>
>> An immutable struct should be similar to an enum... a purely compile time construct not meant to be instantiated in any way.
>
> Why is it you're trying to emulate an enum? Perhaps there's a way to achieve what you want by more normal means.

see my other recent post...

On Monday, 15 July 2013 at 15:08:58 UTC, Dicebot wrote:
> On Monday, 15 July 2013 at 14:50:04 UTC, JS wrote:
>> Why does isMutable and isAssignable return true for a struct/class that are immutable?
>>
>> immutable struct A { }
>>
>> isMutable!A returns true.
>
> looks like
>
> immutable struct A
> {
>     int a;
> }
>
> acts as a
>
> struct A
> {
>     immutable:
>         int a;
> }
>
> Now, I don't see this use case (qualified aggregate definition) anywhere in spec and this may be intended behavior. But I do agree this looks misleading.

and immutability doesn't nest. immutable struct A { struct B { }}, struct B is mutable.

On Monday, 15 July 2013 at 18:39:08 UTC, JS wrote:
> and immutability doesn't nest. immutable struct A { struct B { }}, struct B is mutable.

What I have meant by "may be intended behavior" is that immutable qualifier does not attach at aggregate definitions. At all. It is irrelevant to the fact if B is nested or not.

However, I have just checked and adding a member field to B also leaves it mutable. And that is really frustrating.

Have filed a bugzilla issue: http://d.puremagic.com/issues/show_bug.cgi?id=10649

On Monday, July 15, 2013 21:08:03 Dicebot wrote:
> On Monday, 15 July 2013 at 18:39:08 UTC, JS wrote:
> > and immutability doesn't nest. immutable struct A { struct B { }}, struct B is mutable.
> 
> What I have meant by "may be intended behavior" is that immutable qualifier does not attach at aggregate definitions. At all. It is irrelevant to the fact if B is nested or not.

Yes. Attributes such as immutable or private have no effect on structs or classes, just their members. It's a bit weird that way, but that's the way that it works.

> However, I have just checked and adding a member field to B also leaves it mutable. And that is really frustrating.

That definitely sounds like a bug.

- Jonathan M Davis

On Tuesday, 16 July 2013 at 01:24:37 UTC, Jonathan M Davis wrote:
> On Monday, July 15, 2013 21:08:03 Dicebot wrote:
>> On Monday, 15 July 2013 at 18:39:08 UTC, JS wrote:
>> > and immutability doesn't nest. immutable struct A { struct B {
>> > }}, struct B is mutable.
>> 
>> What I have meant by "may be intended behavior" is that immutable
>> qualifier does not attach at aggregate definitions. At all. It is
>> irrelevant to the fact if B is nested or not.
>
> Yes. Attributes such as immutable or private have no effect on structs or
> classes, just their members. It's a bit weird that way, but that's the way
> that it works.
>
Then we should be able to make a struct immutable itself. e.g., immutable immutable(struct) A makes both A and it's members immutable. An immutable struct makes nested structs also immutable.

>> However, I have just checked and adding a member field to B also
>> leaves it mutable. And that is really frustrating.
>
> That definitely sounds like a bug.
>
> - Jonathan M Davis

On Tuesday, July 16, 2013 03:46:06 JS wrote:
> On Tuesday, 16 July 2013 at 01:24:37 UTC, Jonathan M Davis wrote:
> > On Monday, July 15, 2013 21:08:03 Dicebot wrote:
> >> On Monday, 15 July 2013 at 18:39:08 UTC, JS wrote:
> >> > and immutability doesn't nest. immutable struct A { struct B
> >> > {
> >> > }}, struct B is mutable.
> >> 
> >> What I have meant by "may be intended behavior" is that
> >> immutable
> >> qualifier does not attach at aggregate definitions. At all. It
> >> is
> >> irrelevant to the fact if B is nested or not.
> > 
> > Yes. Attributes such as immutable or private have no effect on
> > structs or
> > classes, just their members. It's a bit weird that way, but
> > that's the way
> > that it works.
> 
> Then we should be able to make a struct immutable itself. e.g., immutable immutable(struct) A makes both A and it's members immutable. An immutable struct makes nested structs also immutable.

The way it works is that immutable on a struct should make anything within that struct (member variables, member functions, etc.) immutable. That should include nested members but apparently does not currently due to a bug. That behavior makes perfect sense to me. Aside from the bug fix, I don't understand what you're trying to gain here. As far as immutability goes, this behavior seems perfectly fine to me. I just find it a bit weird with regards to private, since it makes it so that you can't actually make a struct or class private - just its members. But since you can't do anything to it without accessing its members, AFAIK that behavior doesn't actually cause any problems.

- Jonathan M Davis