Deprecating this(this)

[H. S. Teoh]

On Wed, Apr 04, 2018 at 03:30:39PM -0700, Walter Bright via Digitalmars-d wrote:
> On 4/1/2018 3:49 AM, bachmeier wrote:
> > What I was wondering too. I mean, breaking changes just don't happen
> > to this language. Now there will be, without even an indication of
> > how existing code would have to be rewritten, or how this
> > large-scale breakage is different than the breakages that just can't
> > happen because reasons. I guess that's why there's always the
> > disclaimer, "We'll only break code if there's a really good reason."
> > That reason is "in case we want to".
> 
> The idea is not to introduce a breaking change. Postblits will remain.
> The copy constructor will be an additional construct, and if one is
> defined, it will be preferred.

This may lead to trouble, unless we explicitly make it illegal for
something to have both a postblit and a copy ctor. Having the two
interact with each other seems likely to lead to a lot of pathological,
hard-to-understand results.


> Eventually (years later) postblits will be slowly deprecated and
> eventually removed.

Actually, if it's possible to have them coexist and there are no
disadvantages to doing so, why not just leave both of them in?  Then
cases where postblits give the best performance could just be left
as-is, and cases that require a copy ctor can use a copy ctor.


T

-- 
Klein bottle for rent ... inquire within. -- Stephen Mulraney