digitalmars.D.bugs - [Issue 9656] New: Built-in dup result should behave as like unique array, if it is possible.
- d-bugmail puremagic.com (29/29) Mar 06 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9656
- d-bugmail puremagic.com (12/12) Mar 06 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9656
- d-bugmail puremagic.com (10/15) Mar 06 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9656
- d-bugmail puremagic.com (10/10) Apr 28 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9656
- d-bugmail puremagic.com (8/9) Apr 28 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9656
- d-bugmail puremagic.com (9/11) Apr 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9656
- d-bugmail puremagic.com (13/13) May 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9656
- d-bugmail puremagic.com (23/26) May 10 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9656
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 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
http://d.puremagic.com/issues/show_bug.cgi?id=9656 bearophile_hugs eml.cc changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bearophile_hugs eml.cc 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
http://d.puremagic.com/issues/show_bug.cgi?id=9656A simple question: Why is this not valid? carr = [new C].dup; // NG, expectedThat'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
http://d.puremagic.com/issues/show_bug.cgi?id=9656 Kenji Hara <k.hara.pg gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |pull 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
http://d.puremagic.com/issues/show_bug.cgi?id=9656https://github.com/D-Programming-Language/dmd/pull/1943The 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
http://d.puremagic.com/issues/show_bug.cgi?id=9656But 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
http://d.puremagic.com/issues/show_bug.cgi?id=9656 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 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| |FIXEDI 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