I've found a strange postblit bug (or not a bug?):

************************************

struct A
{
    this(this)
    {
    }
}

struct B
{
    A a;
}


struct C
{
    const B b;
}

void main()
{
    C c;
}

************************************

When I try to compile it, compiler raises the error: (Error: mutable method testaa2.B.__fieldPostBlit is not callable using a const object)

If I mark this(this) as const (BTW, is "this(this) const" a correct definition?) error still raises.
When I tried to reduce this code, I've found the next:

************************************

struct A
{
    this(this)
    {
    }
}

struct B
{
    const A a;
}


void main()
{
    B b;
}

************************************

Error: mutable method testaa2.A.__postblit is not callable using a const object

If I change this(this) to const, error has been lost.

************************************

struct A
{
    this(this) const
    {
    }
}

struct B
{
    const A a;
}


void main()
{
    B b;
}

************************************

Can someone comment this code? Should I think that it's a bug.

On Fri, 17 Oct 2014 00:42:24 +0000
IgorStepanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> Can someone comment this code? Should I think that it's a bug.
it's just an anomaly. const postblit can do alot of things besides adjusting struct fields, and it's logical that compiler cannot call non-const methods for const objects.

yet it's still on of those "unforseen consequences" that arises from conjunction of different features.

i don't think that it's a bug, but i think that this must be discussed anyway, and then documented.

On Friday, 17 October 2014 at 00:55:25 UTC, ketmar via Digitalmars-d wrote:
> On Fri, 17 Oct 2014 00:42:24 +0000
> IgorStepanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Can someone comment this code? Should I think that it's a bug.
> it's just an anomaly. const postblit can do alot of things besides
> adjusting struct fields, and it's logical that compiler cannot call
> non-const methods for const objects.
>
> yet it's still on of those "unforseen consequences" that arises from
> conjunction of different features.
>
> i don't think that it's a bug, but i think that this must be discussed
> anyway, and then documented.

I think, this is unexpected behaviour:

Compiler generates "__fieldPostBlit" for all structs, and call it when postblit is needed.

In this example compiler generates something like the next code:

struct A
{
    this(this)
    {
    }
}

struct B
{
    A a;

    void __fieldPostBlit()
    {
        a.__postblit(); //a has an explicit postblit
    }
}


struct C
{
    const B b;
    void __fieldPostBlit()
    {
        b.__fieldPostBlit(); //Error: b is const
    }
}

void main()
{
    C c;
    C c2 = c; //=>
              //memcpy(&c2, &c, C.sizeof)
              //c2.__fieldPostBlit();

}


However, __postblit and __fieldPostBlit are always called for new object, thus it can neglect const guarantee and generate postblits like:
void __fieldPostBlit()
{
     (cast()b).__fieldPostBlit();
}

On Fri, 17 Oct 2014 01:30:51 +0000
IgorStepanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> I think, this is unexpected behaviour:
that's what i mean when i was talking about "unforeseen consequences". ;-)

when exactly "const" should be in effect? that is the question! ;-) let's wait what other people will say about this.

Am Fri, 17 Oct 2014 00:42:24 +0000
schrieb "IgorStepanov" <wazar@mail.ru>:

OK, I've run into the same problem and there is no line number, just:

Error: immutable method Lib.Sys.File.File.~this is not callable using a mutable object Error: mutable method Lib.Sys.File.File.~this is not callable using a immutable object

haha! I should start from scratch.

-- 
Marco

Am Fri, 17 Oct 2014 14:42:53 +0200
schrieb Marco Leise <Marco.Leise@gmx.de>:

> Am Fri, 17 Oct 2014 00:42:24 +0000
> schrieb "IgorStepanov" <wazar@mail.ru>:
> 
> OK, I've run into the same problem and there is no line number, just:
> 
> Error: immutable method Lib.Sys.File.File.~this is not callable using a mutable object Error: mutable method Lib.Sys.File.File.~this is not callable using a immutable object
> 
> haha! I should start from scratch.

Here is a reduced test case, that I wish I had before I tried to make 1000 lines of code work with immutable:

struct B {
    ~this() { /* some cleanup */ }
}

struct C {
    immutable B b;
}

void main() {
    C(immutable B());
}

That's pretty much it. You cannot use compose a mutable struct out of immutable ones with dtors.

-- 
Marco

On Friday, 17 October 2014 at 00:55:25 UTC, ketmar via Digitalmars-d wrote:
> On Fri, 17 Oct 2014 00:42:24 +0000
> IgorStepanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>
>> Can someone comment this code? Should I think that it's a bug.
> it's just an anomaly. const postblit can do alot of things besides
> adjusting struct fields, and it's logical that compiler cannot call
> non-const methods for const objects.
>
> yet it's still on of those "unforseen consequences" that arises from
> conjunction of different features.
>
> i don't think that it's a bug, but i think that this must be discussed
> anyway, and then documented.

AFAIK, Kenji has submitted a DIP, and has begun working on "fixing" the const/immutable/inout posblit issue.

However, there are some very subtle corner cases, so (afaik) work is slow.

To be honest, I think people use "const" way too much in D. It's *not* the C++ head const you can use anywhere. It's really just the "base" attribute between mutable and immutable data. In particular, due to the transitive nature of const, any time you use const it means "you can't modify this, or anything produced or acquired from this, ever". It's usually not what people think they are signing for...

When it makes little sense to have your type as immutable, then I don't think you should bother much

On Fri, 17 Oct 2014 14:18:30 +0000
monarch_dodra via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> To be honest, I think people use "const" way too much in D. It's *not* the C++ head const you can use anywhere. It's really just the "base" attribute between mutable and immutable data. In particular, due to the transitive nature of const, any time you use const it means "you can't modify this, or anything produced or acquired from this, ever". It's usually not what people think they are signing for...
> 
> When it makes little sense to have your type as immutable, then I don't think you should bother much

const is a nice way to make sure that your data will not be modified. it needs some time to adjust your head to the fact that "const is const all way down to the bytes", but then it's nice.

yet i still missing c++-like const, which will not try to eat everything underneath. i.e. a way to tell compiler "this field cannot be modified, but the data it points to can be changed". this will let me to get rid of annoying getters.

On Friday, 17 October 2014 at 14:18:31 UTC, monarch_dodra wrote:
> On Friday, 17 October 2014 at 00:55:25 UTC, ketmar via Digitalmars-d wrote:
>> On Fri, 17 Oct 2014 00:42:24 +0000
>> IgorStepanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>>> Can someone comment this code? Should I think that it's a bug.
>> it's just an anomaly. const postblit can do alot of things besides
>> adjusting struct fields, and it's logical that compiler cannot call
>> non-const methods for const objects.
>>
>> yet it's still on of those "unforseen consequences" that arises from
>> conjunction of different features.
>>
>> i don't think that it's a bug, but i think that this must be discussed
>> anyway, and then documented.
>
> AFAIK, Kenji has submitted a DIP, and has begun working on "fixing" the const/immutable/inout posblit issue.
>
> However, there are some very subtle corner cases, so (afaik) work is slow.
>
> To be honest, I think people use "const" way too much in D. It's *not* the C++ head const you can use anywhere. It's really just the "base" attribute between mutable and immutable data. In particular, due to the transitive nature of const, any time you use const it means "you can't modify this, or anything produced or acquired from this, ever". It's usually not what people think they are signing for...
>
> When it makes little sense to have your type as immutable, then I don't think you should bother much

What happends if we will ignore const/immutable modifier for postblits? Is it create any holes?

On Fri, 17 Oct 2014 14:41:36 +0000
IgorStepanov via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> What happends if we will ignore const/immutable modifier for postblits? Is it create any holes?
it will break "const promise". i.e. "const/immutable data is not really immutable now, it can be modified".