www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9656] New: Built-in dup result should behave as like unique array, if it is possible.

reply d-bugmail puremagic.com writes:
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: -------
Mar 06 2013
next sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Mar 06 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Apr 28 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Apr 28 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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: -------
Apr 30 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling parent d-bugmail puremagic.com writes:
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: -------
May 10 2013