On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote (in the article):
> The problem is that the entire object must be fully initialized before
> the body of the postblit constructor is run. That means that any member
> variables which are const or immutable are stuck at whatever they were in
> the original object, because it would violate the type system to mutate them. And if an object is const or immutable, then that's all of the members.

I think we have a misunderstanding here. According to that, this would not compile (imports left out):

struct placeAtWorldMap
{   char[] title;
    int[2] coordsMicroDeg;

    this(this)
    {   title = title.dup;
    }
}
void main()
{   char[] title = "London bridge".dup;
    const place = placeAtWorldMap(title, [51_508_038, -87_693]);
    const samePlace = place;
    "falling down ".copy(title);
    place.title.writeln; // falling down
    samePlace.title.writeln; // London bridge
    readln;
}

...but it compiles and correctly runs, and I'm happy about that.

On Tuesday, 6 March 2018 at 10:49:48 UTC, Dukc wrote:
> On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote (in the article):
>> The problem is that the entire object must be fully initialized before
>> the body of the postblit constructor is run. That means that any member
>> variables which are const or immutable are stuck at whatever they were in
>> the original object, because it would violate the type system to mutate them. And if an object is const or immutable, then that's all of the members.
>
> I think we have a misunderstanding here. According to that, this would not compile (imports left out):
>
> struct placeAtWorldMap
> {   char[] title;
>     int[2] coordsMicroDeg;
>
>     this(this)
>     {   title = title.dup;
>     }
> }
> void main()
> {   char[] title = "London bridge".dup;
>     const place = placeAtWorldMap(title, [51_508_038, -87_693]);
>     const samePlace = place;
>     "falling down ".copy(title);
>     place.title.writeln; // falling down
>     samePlace.title.writeln; // London bridge
>     readln;
> }
>
> ...but it compiles and correctly runs, and I'm happy about that.

Quote from the article:

> . That means that any member
> variables which are const or immutable are stuck at whatever they were in
> the original object, because it would violate the type system to mutate them

Meaning that if you declare your `title` member `const char[] title`, you can't change it in the postblit, but you could set it in the constructor.

```
import std.array;
import std.stdio;
import std.algorithm;

struct placeAtWorldMap
{   const char[] title;
    int[2] coordsMicroDeg;

    this(char[] name)
    {
        this.title = name.idup;          // you can assign const members here
    }

    this(char[] name, int[2] coords)
    {
        this.title = name;
        this.coordsMicroDeg = coords;
    }

    this(this)
    {//   title = title.dup;    // doesn't work anymore
    }
}

void main()
{   char[] title = "London bridge".dup;
    const place = placeAtWorldMap(title, [51_508_038, -87_693]);
    const newPlace = placeAtWorldMap("Big Ben".dup);
    const samePlace = place;
    "falling down ".copy(title);
    place.title.writeln; // falling down
    samePlace.title.writeln; // London bridge
    newPlace.title.writeln;      // Big Ben
}
```

On Tuesday, 6 March 2018 at 11:03:24 UTC, Nemanja Boric wrote:
>     title = title.dup;    // doesn't work anymore

Strange! You're right it does not when the type declares a member as const, yet:

>> On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote (in the article):
>>> And if an object is const or immutable, then that's all of the members.


...does not prevent the postblit from working whenthe object is declared const by user.

I think we have a bug here. I believe postblits should behave like constructors in both events.

On Tuesday, 6 March 2018 at 12:05:26 UTC, Dukc wrote:
> I think we have a bug here. I believe postblits should behave like constructors in both events.

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

On Tuesday, 6 March 2018 at 10:02:10 UTC, Radu wrote:
> On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote:
>> Here's something I wrote up on const:
>>
>> http://jmdavisprog.com/articles/why-const-sucks.html
>>
>> I suppose that it's not exactly the most positive article, but I feel that it's accurate.
>>
>> - Jonathan M Davis
>
> Spot on article, and touches some of my pain points when working with const/immutable structs.
>
> Recently I tried to create a ref-counted immutable struct, oh boi...
>
> This later use case is of tremendous value for safe concurrent code that's @nogc. Unfortunately I couldn't find a way to make it work efficiently and in the same time not look like a disgusting hack.
>
> I suspect a possible solution is to allow immutable(const) postblit overloads as well as immutable dtors that will act as an escape hatch for unsafe work and in the same time provide hints that you are operating on an immutable(const) this.

AFAIK this is a solved problem. Dicebot (not sure if he's still around) had initially proposed it: store the reference count just before the immutable piece of memory.

| ref count |    object/struct    |

In fact, Andrei added a new allocator to std.experimental.allocator to support this:

https://dlang.org/library/std/experimental/allocator/building_blocks/affix_allocator/affix_allocator.prefix.html

On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote:
> Here's something I wrote up on const:
> /snip

May be not entirely related, but a little gotcha.

given:

interface XY {}

class Foo: XY {}
class Bar: XY {}

void doSomething(in XY sth)
{
  auto foo = cast(Foo)sth; // error in @safe code
}

But the compiler doesn't emit a warning that const got cast away in @system code.
Since @system is the default setting and casting const away is by definition undefined behavior, there should be some feedback.

If you cast away const in C++ you need to be explicit about it by using const_cast, documents the intention rather than D's swiss-army-cast.

On 3/8/18 9:58 AM, joe wrote:
> On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote:
>> Here's something I wrote up on const:
>> /snip
> 
> May be not entirely related, but a little gotcha.
> 
> given:
> 
> interface XY {}
> 
> class Foo: XY {}
> class Bar: XY {}
> 
> void doSomething(in XY sth)
> {
>    auto foo = cast(Foo)sth; // error in @safe code
> }
> 
> But the compiler doesn't emit a warning that const got cast away in @system code.
> Since @system is the default setting and casting const away is by definition undefined behavior, there should be some feedback.
> 
> If you cast away const in C++ you need to be explicit about it by using const_cast, documents the intention rather than D's swiss-army-cast.

This is a problem with the cast system, not const. D has one cast mechanism, and it's used to:

a) dynamic type cast
b) hook user-supplied opCast
c) enter undefined behavior by casting away const/immutable.

I really think we should have a separate mechanism for a and b, as they are far less dangerous than c.

std.conv.to does this as well, but the language should have some safeguards against using "safe casting" incorrectly.

-Steve

On Thursday, 8 March 2018 at 15:13:09 UTC, Steven Schveighoffer wrote:
> On 3/8/18 9:58 AM, joe wrote:
>> On Monday, 5 March 2018 at 10:57:35 UTC, Jonathan M Davis wrote:
>>> Here's something I wrote up on const:
>>> /snip
>> 
>> May be not entirely related, but a little gotcha.
>> 
>> given:
>> 
>> interface XY {}
>> 
>> class Foo: XY {}
>> class Bar: XY {}
>> 
>> void doSomething(in XY sth)
>> {
>>    auto foo = cast(Foo)sth; // error in @safe code
>> }
>> 
>> But the compiler doesn't emit a warning that const got cast away in @system code.
>> Since @system is the default setting and casting const away is by definition undefined behavior, there should be some feedback.
>> 
>> If you cast away const in C++ you need to be explicit about it by using const_cast, documents the intention rather than D's swiss-army-cast.
>
> This is a problem with the cast system, not const. ...

I figured. Sorry for off topic.

> ... D has one cast mechanism, and it's used to:
>
> a) dynamic type cast
> b) hook user-supplied opCast
> c) enter undefined behavior by casting away const/immutable.
>
> I really think we should have a separate mechanism for a and b, as they are far less dangerous than c.
>
> std.conv.to does this as well, ...

Thanks for pointing this out.

> ...but the language should have some safeguards against using "safe casting" incorrectly.
>
> -Steve

yes, that's what I was aiming for :)

This one got me because I assumed, with all the improved security in place, D would never silently do such a thing...
Assumptions, right? ...the root of all evil. I should know better. haha.

Anyways, thanks for the insight and have a nice Sunday.