Thread overview
[Issue 9656] New: Built-in dup result should behave as like unique array, if it is possible.
Mar 06, 2013
Kenji Hara
Mar 06, 2013
Kenji Hara
Apr 28, 2013
Kenji Hara
May 10, 2013
yebblies
March 06, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9656

           Summary: Built-in dup result should behave as like unique
                    array, if it is possible.
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: rejects-valid
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: k.hara.pg@gmail.com


--- Comment #0 from Kenji Hara <k.hara.pg@gmail.com> 2013-03-06 01:17:32 PST ---
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
    }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 06, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9656


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #1 from bearophile_hugs@eml.cc 2013-03-06 02:06:50 PST ---
(In reply to comment #0)

A simple question: Why is this not valid?

carr = [new C].dup;  // NG, expected

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 06, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9656



--- Comment #2 from Kenji Hara <k.hara.pg@gmail.com> 2013-03-06 04:32:16 PST ---
(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;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 28, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9656


Kenji Hara <k.hara.pg@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull


--- Comment #3 from Kenji Hara <k.hara.pg@gmail.com> 2013-04-28 01:44:16 PDT ---
https://github.com/D-Programming-Language/dmd/pull/1943

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 28, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9656



--- Comment #4 from bearophile_hugs@eml.cc 2013-04-28 03:04:28 PDT ---
(In reply to comment #3)
> https://github.com/D-Programming-Language/dmd/pull/1943

The patch seems nice. But maybe we should have a language-level way (like an annotation) to denote some reference data as unique.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
April 30, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9656



--- Comment #5 from bearophile_hugs@eml.cc 2013-04-30 09:48:13 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 10, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9656



--- Comment #6 from github-bugzilla@puremagic.com 2013-05-10 05:48:15 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/f5528d3f1f9dbac5e0ca6cb15d25e17bb40db15e
fix Issue 9656 - Built-in dup result should behave as like unique array, if it
is possible

https://github.com/D-Programming-Language/dmd/commit/50e32e6ffae6e2051e0296f4779eb3aa2ce9c2b3 Merge pull request #1943 from 9rnsr/fix9656

Issue 9656 - Built-in dup result should behave as like unique array, if it is possible.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 10, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=9656


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |yebblies@gmail.com
         Resolution|                            |FIXED


--- Comment #7 from yebblies <yebblies@gmail.com> 2013-05-10 22:54:50 EST ---
> 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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------