Deprecating this(this)

[H. S. Teoh]

On Wed, Apr 04, 2018 at 05:08:26PM -0600, Jonathan M Davis via Digitalmars-d wrote:
[...]
> AFAIK, the only real advantage to a postblit constructor is that you
> don't have to explicitly copy everything like you do when declaring a
> copy constructor in C++ - you just change the parts that need to be
> changed after the copy is made in order to make it a deep copy or do
> whatever you need to do to finish making the copy what it should be.
> As such, if we define copy constructors in a way that only requires
> listing the members that are actually going to be different from the
> default copy, then I really don't see an advantage to postblit
> constructors.

That's a very interesting concept.  It could be a nice way of bridging
current semantics over to the new semantics.  Some of the existing
postblit code might even be usable as-is, when reinterpreted in this
way!


> Hmmm. And actually, thinking about that, I almost wonder if we could
> just change this(this) to be a copy constructor. Assume for a moment
> that inside this(this), we provide a new symbol that is the this
> pointer/reference for the original. We then have make it so that any
> member variable in the newly constructed object which is read before
> it is assigned is default-copied. As such,
> 
> this(this)
> {
> }
> 
> would just default-copy everything basically as it does now.

Why even bother with declaring an empty this(this)?  Just leave it out,
and the compiler assumes default-copy.


> And if you currently had
> 
> this(this)
> {
>     _foo = _foo.dup;
> }
> 
> then after the change, it would still have the same semantics, because
> the _foo is used before it is assigned, so it must be default-copied.

That's a pretty neat way of transitioning from current semantics to new
semantics.  I like it.


> However, if we provide the object being copied via an invisible ref
> (like this) called orig, doing
> 
> this(this)
> {
>     _foo = orig._foo;
> }
> 
> then that would directly initialize _foo without it being
> default-copied. As such, existing postblit constructors should
> continue to work, but it would be straightforward to turn them into
> copy constructors, and most of the changes would be underneath the
> hood.
[...]

I like this idea.  Except the syntax could be improved:

	this(this orig)		// <-- N.B.
	{
		_foo = orig._foo;
	}

Let the user specify the symbol, instead of introducing yet another
implicit magic identifier. :-)


T

-- 
"I suspect the best way to deal with procrastination is to put off the
procrastination itself until later. I've been meaning to try this, but
haven't gotten around to it yet. " -- swr