On Wednesday, 6 February 2013 at 18:15:53 UTC, Dan wrote:
>
> Start with:
>
> struct X {
>   char c[];
> }
>
> Assume you want value semantics - postblit provides this capability. It appears with 2.061 'this(this) const' is now supported. Previously, only 'this(this)' was recognized (i.e. called) when expected. To get value semantics a developer must choose between these two and for this case the goal is to ensure 'c = c.dup;' so value semantics are preserved.
>
> Case 1: Go with 'this(this) { c = c.dup; }'. This works just fine except for the case where you want a const(X) as a member of some other class. For example: struct Y { const(X) x; }.
>
> Case 2: Go with 'this(this) const { c = c.dup; }'. This is not possible because you can not change 'c' since the function is const. Maxim Fomin pointed out a workaround.
>

Both are bugs, as const constructor are supposed to be able to set const variable once. See TDPL for reference on that.

> struct X {
>   char c[];
>   void _postblit_() { c = c.dup; }
>   this(this) const {
>     void delegate() dg = &_postblit_;
>     dg();
>   }
> }
>

This is also a bug as transitivity of const isn't respected.

Welcome in weirdland !

On Thursday, 7 February 2013 at 05:30:27 UTC, Maxim Fomin wrote:
> On Wednesday, 6 February 2013 at 22:54:40 UTC, Dan wrote:
>> This begs the question:
>>
>> Which of these do you choose and for what reasons:
>> - this(this){}
>
> This is natural way to define struct postblit. This fully complies with current D spec. This should be used until postblit constness problem is faced.
>
>> - this(this)const{}
>
> This is not normal way to define struct postblit but which happens to work. Spec is silent about this. If you encounter "postblit is not callable using const" message, you can workaround the problem by making postblit const and forwarding call to some other non-const method which actually does postblitting. This is type system breakage which can be useful until option 1 is fixed. Or you may use other workarounds.
>
>> - this(const this){}
>
> This is a tricky and unintuitive way to define simple struct constructor which may be confused with postblit. It actually means
>
> struct S { this(const S s){...} }
>
> and can be written in this way to avoid confusion.
>
>> Also, has any of this detailed information made it into the language spec?
>
> #1 is fully defined in struct chapter. #2 is not defined. #3 is a particular example of omitting parameter names like void foo(int) { }. D unlike C supports omitting parameter names not only in function declaration, but in function definition too.
>

Immensely helpful answer, thanks!

So: Prefer #1. If you get compile error requiring postblit () const, take advantage of #2. Assume/hope that in the future there will never be a requirement to have 'this(this) const' and you can revert to #1 and remove the delegate trick that allowed you to set members in 'this(this) const'.

Regarding #2, not only does it work, in some cases it is required. I know of 2 cases:

struct S {
  this(this) { c=c.dup; }
  char[] c;
}
struct X {
  const(S) s;
}

So my guess is something about the "lowering" or autogenerated postblit of X requires the postblit to be const. I think this is overkill and maybe the 'const'ness of a member of S should be relaxed in the creation of it.

Another is the following fails to compile:

import std.stdio;
struct S {
  this(this) { c=c.dup; }
  char[] c;
}
void main() {
  const(S)[int] s1;
  const(S)[int] s2;
  writeln(s1==s2);
}

Something about opEquals is requiring the signature on S's this(this) to be 'this(this) const'. This really highlights two issues: First, the implementation of opEquals for a hash should *not* need to make copies of the values. There is probably an iteration in the implementation that should be changed to ref. The second is you should probably be allowed to construct a const(S) from another const(S) without requiring signature 'this(this) const' in all cases.

This sort of issue comes up in the weirdest of situations.

http://dpaste.dzfl.pl/f8ddc666
This code compiles. But interestingly making the 'static if(1)' causes it to fail to compile. Somehow, adding a 'opEquals const' to T triggers the generation of a opEquals in X that requires S[int] to have 'opEquals const', which in turn requires S to have 'this(this) const'.

Why so much focus on new features like properties when the fundamentals of const for structs are not hammered out sufficiently?

Thanks
Dan

On 02/07/2013 02:49 PM, Dan wrote:
> ...
>
> Why so much focus on new features like properties

I guess because it is not a new feature, but another part where some things have not been hammered out sufficiently. (Also, it tends to generate larger threads. :o) )

> when the fundamentals of const for structs are not hammered out sufficiently?
> ...

const/immutable type checking currently is unsound during object construction in general.

On Thursday, 7 February 2013 at 15:03:20 UTC, Timon Gehr wrote:
>
> const/immutable type checking currently is unsound during object construction in general.

properties => candy
const/immutable soundness => meat & potatoes

Evidence of tremedous energy and intellect here:
http://forum.dlang.org/thread/ririagrqecshjljcdubd@forum.dlang.org#post-ririagrqecshjljcdubd:40forum.dlang.org

Why can't we harness that energy to fix more of the meat & potatoes problems that exist and have existed for a while?

It seems the focus of initiatives are skewed toward 'wow' features and truly neat enhancements to D. But the original claims and promise of D on a certain level is within reach if the focus is on the more mundane.

Thanks
Dan

On 2013-02-06 23:14, Maxim Fomin wrote:
> On Wednesday, 6 February 2013 at 21:47:35 UTC, Dan wrote:
>> On Wednesday, 6 February 2013 at 20:30:40 UTC, Maxim Fomin wrote:
>>> The fact that bar() does not work and (&bar)() works is terrific.
>>
>> Sorry - but I don't understand what is terrific? Is this sarcasm?
>
> This means it is a huge hole in a type system.

Ah, so you meant: terrifying or horrific. :)

On Thursday, 7 February 2013 at 15:28:39 UTC, Dan wrote:
> On Thursday, 7 February 2013 at 15:03:20 UTC, Timon Gehr wrote:
>>
>> const/immutable type checking currently is unsound during object construction in general.
>
> properties => candy
> const/immutable soundness => meat & potatoes
>
> Evidence of tremedous energy and intellect here:
> http://forum.dlang.org/thread/ririagrqecshjljcdubd@forum.dlang.org#post-ririagrqecshjljcdubd:40forum.dlang.org
>
> Why can't we harness that energy to fix more of the meat & potatoes problems that exist and have existed for a while?
>
> It seems the focus of initiatives are skewed toward 'wow' features and truly neat enhancements to D. But the original claims and promise of D on a certain level is within reach if the focus is on the more mundane.
>

Well because it is known what have to be done for a while. It is "just" not implemented.

On Friday, 8 February 2013 at 04:41:42 UTC, deadalnix wrote:
> Well because it is known what have to be done for a while. It is "just" not implemented.

If it is known then please tell the plan. I see many conflicting points and I don't see the clean solution that maybe you do.

Just from this thread we have that 'this(this) const' is kind of a mistake and not defined in the docs. Yet in certain cases that is a required signature.

Repeating this from:
http://forum.dlang.org/thread/CAFDvkcvvL8GxHQB=Rw9pTm-uxOKzNGVQNDv9w5Os3SkQCc=DLQ@mail.gmail.com

   > Qualified postblits make no sense, given that if
   > the object is const or immutable, you _can't_
   > alter it without violating the type system. But
   > without them, you can't copy const or immutable
   > objects which require a postblit.  Walter and
   > Andrei have stated in the past that they had a
   > plan for solving this, but AFAIK, they've never
   > actually revealed what it is. My best guess would
   > be to introduce copy constructors for const and
   > immutable objects, but I don't know. Regardless,
   > this is a situation that definitely needs to be
   > clarified and properly sorted out.
   >
   > - Jonathan M Davis

Ultimately, though it would be great to know not just what can't work or what might work but what the long term solution is.

Is there a solution ironed out between Andrei and Walter and if so what is it, roughly?

What is the priority of this issue, where the issue is not necessarily the implementation but letting us know where it is going so we can not do something silly?

Realistically, when const gets too much in the way one recourse is to drop it. On the other hand if a solution is in the works and delegate trickery is just a stop gap it's less worrisome.


Thanks
Dan