DIP29: make dup functions pure

[WalterBright]

This adds attributes pure, nothrow, and @trusted to the .dup internal function.

It also allows for better unique detection on the arguments to adDup(). For example, adDup(null) should be implicitly convertible.

[bearophile]

Awesome.

[ghost]

Github doesn't have messaging, so I'll just post this here:

@WalterBright @yebblies @9rnsr @donc @braddr @MartinNowak @andralex @ibuclaw @rainers @klickverbot:
Please take a look at this forum thread, your input would be very welcome!

[andralex]

I think there's a problem with nothrow here. What if we duplicate T[] and the postblit of T throws?

[andralex]

@AndrejMitrovic is there a relationship between the DMD Source Guide and this pull request?

[ghost]

@AndrejMitrovic is there a relationship between the DMD Source Guide and this pull request?

No, Github foolishly got rid of messaging so this is left as one of the workaround ways of notifying people.

[WalterBright]

Hmm, I didn't consider postblit. Will fix.

[MartinNowak]

nothrow seems to fail here

[JakobOvrum]

Wasn't there a PR that moved dup and idup into object.d? @9rnsr

[9rnsr]

Wasn't there a PR that moved dup and idup into object.d?

Was: dlang/druntime#298

[MartinNowak]

Let's fix this now and move it to druntime later.
As druntime function it would allow nothrow for nothrow postblits.

[MartinNowak]

This meansidup will become obsolete?

[monarchdodra]

I think there's a problem with nothrow here.

Obviously, the argument also holds against unconditionally marking it as pure or @trusted too.

[MartinNowak]

Obviously, the argument also holds against unconstitutionally marking it as pure or @trusted too.

True that, so does it even make sense to implement this in the compiler when a simple runtime template would do attribute inference?

T[] dup(T)(T[] arr)
{
    auto res = new T[](arr.length);
    res[] = arr[];
    return res;
}

[andralex]

@MartinNowak the code is less efficient than it should be because the new call initializes the memory. Anyhow the point is well taken: if we can move dup from the compiler to object.d that would be a great win.

[andralex]

Looking at the amount of code dedicated to this, my conviction is even stronger. Let's move dup into the library!!!

[monarchdodra]

the code is less efficient than it should be because the new call initializes the memory.

To obtain GC.memory with standard appendable chunk and non-initialization, one can simply use druntime's reserve, followed by assumeSafeAppend (or _d_arraysetcapacity => gives capacity, then _d_arrayshrinkfit => sets "used up" data).

From there, res[] = arr[]; would mostly work, but it would also destroy res's items afterwards. We could simply use memcpy followed by typeid().postblit to avoid that. But...

The problem here is that while all this is doable in druntime, we'd still just be at square 1, where we wouldn't actually have the correct inference :/ on all of that.

[andralex]

@monarchdodra what would be the attribute inference there?

[monarchdodra]

@monarchdodra what would be the attribute inference there?

That's my point: Implementing dup as a high efficiency druntime function lacks a "direct postblit call" that would trigger inference.

[andralex]

I still don't understand but no matter. Bottom line is less compiler magic and more D stuff that actually looks and feels like legit D code == good.

[WalterBright]

new plan: dlang/druntime#758