On 4/1/18 6:04 AM, Johannes Loher wrote:
> This seems really sudden, april fool's joke? Not really sure, as there
> are real problems with this(this)...

I'm glad I've sent it yesterday then at least in my time zone :o).

This looks sudden but isn't. Eduard and I have been blocked by this problem seriously whilst working on the collections library.


Andrei

On Sunday, 1 April 2018 at 10:04:04 UTC, Johannes Loher wrote:
> This seems really sudden, april fool's joke? Not really sure, as there are real problems with this(this)...

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".

On Sunday, 1 April 2018 at 10:49:22 UTC, bachmeier wrote:
> On Sunday, 1 April 2018 at 10:04:04 UTC, Johannes Loher wrote:
>> This seems really sudden, april fool's joke? Not really sure, as there are real problems with this(this)...
>
> 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".

Nothing has been lay out yet and people are already freaking out. No wonder nothing gets done anymore.

On Saturday, 31 March 2018 at 23:38:06 UTC, Andrei Alexandrescu wrote:
>
> * immutable and const are very difficult, but we have an attack (assuming copy construction gets taken care of)
>
> * pure is difficult
>

How about removing pure, const and immutable?

On Sunday, 1 April 2018 at 01:01:24 UTC, Jonathan M Davis wrote:
> So, I think that the only large-scale benefit thet exists for pure and really can exist for pure is the fact that you know that the function doesn't access global, mutable state. Everything else it does is just gravy and too limited to be a "large-scale" benefit. Certainly, optimizations are clearly _not_ the main benefit of pure, since they almost don't exist. But over time, we have managed to add more gravy here and there as we've figured out assumptions that can be made based on pure (like the case where we can convert the result of a pure function to immutable).
>
> - Jonathan M Davis

Great write-up.

Why keep pure when the benefits obviously don't outweight the costs?
Here is what I interpret reading this: "lost productivity".

On Sunday, 1 April 2018 at 01:56:40 UTC, Jonathan M Davis wrote:
> Another potential issue is whether any of this does or should relate to
>
> https://github.com/dlang/DIPs/pull/109
>
> and it's solution for hooking into to moves. I'm not at all sure that what happens with that needs to be related to this at all, but it might.
>
> - Jonathan M Davis

And before we think about `opMove` we should, IMO, make the compiler pass by move in more cases, for instance, in range constructors such as

this(Source source)
{
    this.source = source; // last occurrence of `source` can be moved
}

I'd be happy to help out with adding this in dmd. Andrei has already showed interest in this idea.

On Sunday, April 01, 2018 11:37:21 Guillaume Piolat via Digitalmars-d wrote:
> On Sunday, 1 April 2018 at 01:01:24 UTC, Jonathan M Davis wrote:
> > So, I think that the only large-scale benefit thet exists for pure and really can exist for pure is the fact that you know that the function doesn't access global, mutable state. Everything else it does is just gravy and too limited to be a "large-scale" benefit. Certainly, optimizations are clearly _not_ the main benefit of pure, since they almost don't exist. But over time, we have managed to add more gravy here and there as we've figured out assumptions that can be made based on pure (like the case where we can convert the result of a pure function to immutable).
> >
> > - Jonathan M Davis
>
> Great write-up.
>
> Why keep pure when the benefits obviously don't outweight the
> costs?
> Here is what I interpret reading this: "lost productivity".

Personally, I don't think that the costs outweigh the benefits. Yes, if your primary goal is optimizations, then pure falls flat on its face, but personally, I think that the fact that pure allows you to prove that a function doesn't access any global, mutable state except through its arguments is quite valuable. There are still some things in druntime and Phobos which don't work with pure like they should, but in general, I haven't found that it's really a big problem. Some code can't be pure, and that's life, but a _lot_ can be. If anything, I find that const is the attribute that causes problems, not pure.

But if you don't want to use pure, then don't use pure. Nothing is forcing you to use it, and if someone else insists on making their code work with pure, it's only a problem for you if they're trying to call your code, and they complain about the fact that your code doesn't work with pure. Certainly, code that isn't pure has no problems calling code that is, so if other folks go to the effort of making their code work with pure, it won't cause you problems.

- Jonathan M Davis

On Sunday, April 01, 2018 12:23:29 Per Nordlöw via Digitalmars-d wrote:
> On Sunday, 1 April 2018 at 01:56:40 UTC, Jonathan M Davis wrote:
> > Another potential issue is whether any of this does or should relate to
> >
> > https://github.com/dlang/DIPs/pull/109
> >
> > and it's solution for hooking into to moves. I'm not at all sure that what happens with that needs to be related to this at all, but it might.
> >
> > - Jonathan M Davis
>
> And before we think about `opMove` we should, IMO, make the compiler pass by move in more cases, for instance, in range constructors such as
>
> this(Source source)
> {
>      this.source = source; // last occurrence of `source` can be
> moved
> }
>
> I'd be happy to help out with adding this in dmd. Andrei has already showed interest in this idea.

I don't see what that has to do with opMove other than the fact that in such cases, you'd then end up with opMove being called instead of the postblit constructor. It seems to me that whether opMove is part of the language or not when such improvements are made is irrelevant. They should be able to be done independently of one other.

As I understand it, the motivations behind opMove really have nothing to do with how often moves are made vs copying. It has to do with types that have serious issues if they're moved. The Weka guys (and probably others) have use cases where the fact that an object is moved without any way for them to detect it and do stuff like update pointers to the object is a serious problem. If anything, their use case might be better off right now if _no_ moves were ever done (at least until something like opMove is in the language), since the moves result in bugs.

- Jonathan M Davis

On 04/01/2018 03:08 AM, Andrei Alexandrescu wrote:
> On 3/31/18 8:32 PM, H. S. Teoh wrote:
[...]
>> What exactly is it about this(this) that blocks us from doing that?
> 
> See the updated docs. Too many bugs in design and implementation.
> 
>> Removing this(this) is going to be a huge breaking change far bigger
>> than, say, removing autodecoding ever will be.
> 
> We're not removing it as much as evolving it: we define an alternate copying mechanism, and once that is in tip-top shape, we deprecate this(this).

Is there a fundamental flaw in the postblit idea, or are you just going to give postblit a new syntax, and try to avoid all the issues that `this(this)` currently has?

If there's a fundamental flaw, I'd be interested in what it is. I can't make it out in your additions to the spec, if it's in there. I can see that `this(this)` is  a mess, but it also looks like a lot could be fixed. For example, how it interacts with const/immutable is ridiculous, but that could probably be fixed.

If you're just going for a clean slate, I can see the appeal. You avoid dealing with the hard breakage that fixing `this(this)` would most probably bring.

On Sunday, April 01, 2018 14:55:07 ag0aep6g via Digitalmars-d wrote:
> On 04/01/2018 03:08 AM, Andrei Alexandrescu wrote:
> > On 3/31/18 8:32 PM, H. S. Teoh wrote:
> [...]
>
> >> What exactly is it about this(this) that blocks us from doing that?
> >
> > See the updated docs. Too many bugs in design and implementation.
> >
> >> Removing this(this) is going to be a huge breaking change far bigger than, say, removing autodecoding ever will be.
> >
> > We're not removing it as much as evolving it: we define an alternate copying mechanism, and once that is in tip-top shape, we deprecate this(this).
>
> Is there a fundamental flaw in the postblit idea, or are you just going to give postblit a new syntax, and try to avoid all the issues that `this(this)` currently has?
>
> If there's a fundamental flaw, I'd be interested in what it is. I can't make it out in your additions to the spec, if it's in there. I can see that `this(this)` is  a mess, but it also looks like a lot could be fixed. For example, how it interacts with const/immutable is ridiculous, but that could probably be fixed.

One issue is that postblit constructors fundamentally don't work with const. The problem is that a postblit constructor works by copying the object and _then_ mutating it, and you can't mutate a const object. To cleanly deal with const, you need something more like a copy constructor where you initialize it with the adjusted values directly rather than mutating the copy.

> If you're just going for a clean slate, I can see the appeal. You avoid dealing with the hard breakage that fixing `this(this)` would most probably bring.

Avoiding any breakage would be ideal, but it's unlikely that that can be done if we want to make copying const objects work properly - not unless we did something like use postblit constructors for mutable objects and copy constructors for const objects, and that would just cause other problems (including having to duplicate the code that deals with copying an object if it's going to work with const). On the bright side, if we're replacing postblit constructors with some other type of constructor for copying, it should be a pretty straightforward process. But there isn't much point in worrying about how much breakage there's going to be before we really know where we want to go with this. At this point, it's just clear that as things stand, postblit constructors have some definite problems (some which are implementation issues and some which are language design issues), and based on past discussions on this and previous attempts to fix some of the problems with postblit constructors, it seems pretty unlikely that we can fully fix postblit constructors. I'm sure that we could fix some of the issues, but others (most notably, the issues with const) seem pretty intractable.

- Jonathan M Davis