https://issues.dlang.org/show_bug.cgi?id=18561

ag0aep6g@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ag0aep6g@gmail.com
         Resolution|---                         |DUPLICATE

--- Comment #1 from ag0aep6g@gmail.com ---
(In reply to Ajieskola from comment #0)
> Postblits behave inconsistently with constants. As shown in the second example, it cannot modify members which are declared as const. But if that is wrong, the first one should compile neither, as all the members should be treated as const when the whole variable is const.

The first example shouldn't compile.

`title = title.dup;` doesn't do any actual harm, because you're not altering the original. But consider `title[0] = 'W';`. Now you're changing the original `title` to "Wondon bridge", and you're doing it through a `const` reference. That should not be possible. Even worse, the original title could be `immutable`:

----
import std.stdio;
struct placeAtWorldMap
{   char[] title;

    this(this)
    {   title[0] = 'W'; /* ! */
    }
}
void main()
{   immutable char[] title = "London bridge".dup;
    const place = const placeAtWorldMap(title);
    const samePlace = place;
    title.writeln; // Wondon bridge
}
----

Issue 18357 already covers that problem. Closing as DUPLICATE. Feel free to revert if you think it's not an exact duplicate.

*** This issue has been marked as a duplicate of issue 18357 ***

--

https://issues.dlang.org/show_bug.cgi?id=18561

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |schveiguy@yahoo.com
         Resolution|DUPLICATE                   |---
            Summary|postblit behaves            |postblit should allow
                   |inconsistently with         |writing const/immutable
                   |constants                   |members just like
                   |                            |constructors

--- Comment #2 from Steven Schveighoffer <schveiguy@yahoo.com> ---
I think the OP has a point here.

A more direct example:

struct S
{
   const char[] t;
   this(this)
   {
      t = t.dup;     // this should be allowed
      // t[0] = 'w'; // this should not
   }
}

S s;

// Should be OK, calls postblit, s2 is new data.
auto s2 = s;

// error cannot overwrite const (does not call postblit). This happens already
s = s2;

essentially, when READING `this`, all normal rules apply. When WRITING members of `this`, everything should be considered tail-X, where X is const, immutable, etc. If we have any immutable or const data as members, the compiler should have already forbade it if you couldn't overwrite it before the postblit.

It's the same as constructors, but for constructors, `this` didn't exist yet. If we get to a postblit on a type that has const or immutable data, we have the same guarantee.

This does not address postblits being called on const data types (with `this` being mutable during the postblit). That is a different bug.

--

https://issues.dlang.org/show_bug.cgi?id=18561

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Hardware|x86                         |All
                 OS|Windows                     |All

--

https://issues.dlang.org/show_bug.cgi?id=18561

--- Comment #3 from anonymous4 <dfj1esp02@sneakemail.com> ---
This passes:
---
struct A
{
    int a;
    this(int b) const { a=b; }
}
int main()
{
    const A a;
    assert(a.a==0,"0");
    a.__ctor(1);
    assert(a.a==1,"1");
    return 0;
}
---

--

https://issues.dlang.org/show_bug.cgi?id=18561

--- Comment #4 from Ajieskola@gmail.com ---
(In reply to anonymous4 from comment #3)
> This passes:
> ---
> struct A
> {
>     int a;
>     this(int b) const { a=b; }
> }
> int main()
> {
>     const A a;
>     assert(a.a==0,"0");
>     a.__ctor(1);
>     assert(a.a==1,"1");
>     return 0;
> }
> ---

I believe it should not. Yes, constructor should be able to do that, but only when used as a constructor. But it is a separate issue from this one.

--

https://issues.dlang.org/show_bug.cgi?id=18561

--- Comment #5 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(In reply to anonymous4 from comment #3)
>     a.__ctor(1);

This is another bug. One should only be able to call const __ctor on a struct once, before using it.

--

https://issues.dlang.org/show_bug.cgi?id=18561

--- Comment #6 from anonymous4 <dfj1esp02@sneakemail.com> ---
(In reply to Steven Schveighoffer from comment #2)
> This does not address postblits being called on const data types (with `this` being mutable during the postblit). That is a different bug.
I thought you meant this. As you can see const constructor can be already called on const data, ability to call const postblit wouldn't be different.

--

https://issues.dlang.org/show_bug.cgi?id=18561

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |razvan.nitu1305@gmail.com
         Resolution|---                         |WONTFIX

--- Comment #7 from RazvanN <razvan.nitu1305@gmail.com> ---
Postblit is a flawed design and will not be pursued. Closing this as WONTFIX.

--

https://issues.dlang.org/show_bug.cgi?id=18561

--- Comment #8 from Ate Eskola <Ajieskola@gmail.com> ---
And the issue is in practice solved by copy constructors anyway, thanks to you :). They didn't exist when I raised this issue but now they do.

--