Bug 9656 – Built-in dup result should behave as like unique array, if it is possible.
Status
RESOLVED
Resolution
FIXED
Severity
normal
Priority
P2
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-03-06T01:17:00Z
Last change time
2013-05-10T05:54:50Z
Keywords
pull, rejects-valid
Assigned to
nobody
Creator
k.hara.pg
Comments
Comment #0 by k.hara.pg — 2013-03-06T01:17:32Z
In below, narr = [1,2,3].dup should work.
class C {}
struct S {
immutable int[] narr;
immutable C[] carr;
this(int n) {
narr = new int[](3); // OK, expected
narr = [1,2,3].dup; // NG, rejects-valid
carr = [new C].dup; // NG, expected
}
}
Comment #1 by bearophile_hugs — 2013-03-06T02:06:50Z
(In reply to comment #0)
A simple question: Why is this not valid?
carr = [new C].dup; // NG, expected
Comment #2 by k.hara.pg — 2013-03-06T04:32:16Z
(In reply to comment #1)
> (In reply to comment #0)
>
> A simple question: Why is this not valid?
>
> carr = [new C].dup; // NG, expected
That's right, the dup result is essentially unique in it.
Correct NG case is:
auto c = new C;
carr = [c].dup;
Comment #5 by bearophile_hugs — 2013-04-30T09:48:13Z
(In reply to comment #4)
> But maybe we should have a language-level way (like an
> annotation) to denote some reference data as unique.
I am ignorant regarding the compiler, but ,aybe in the meantime it's enough to have an invisible "unique" attribute used just by the compiler-front end, like the various PUREimpure, PUREfwdref, etc used in the compiler.
Comment #6 by github-bugzilla — 2013-05-10T05:48:15Z
> I am ignorant regarding the compiler, but ,aybe in the meantime it's enough to
> have an invisible "unique" attribute used just by the compiler-front end, like
> the various PUREimpure, PUREfwdref, etc used in the compiler.
So far we've been going in the direction of 'unique expressions' whereby the fact they allocate new memory or call pure functions etc is enough to ensure they are unique.
The funny thing about this one is that this function:
int[] dup(const(int)[] data) pure
{
return data.dup;
}
was already creating a unique result, while the builtin was not. (I haven't tested that exact code, but something along those lines should work)
The purity+allocation pattern for normal functions should allow many library types to create unique data, without needing additional attributes.