http://d.puremagic.com/issues/show_bug.cgi?id=10950
--- Comment #6 from [email protected] 2013-09-04 02:00:40 PDT --- (In reply to comment #5) > You seem to be expecting the .dup to act as a macro, and be automatically > applied to any code that uses the enum? No, not at all. I expect that when I use CTFE that evaluates a function to initialize an enum, for it work correctly. > None of your test cases should compile. Should this compile? //---- import std.exception; string getString() { char[] s = ['a', 'b']; return assumeUnique(s); } enum string myString = getString(); char[] getArray() { string s = "hello"; return s.dup; } enum char[] myArray = getArray(); unittest { //myString is a string enum, so there should be no allocation. string a = myString; string b = myString; assert(a is b); //This fails. It shouldn't. } unittest { //myArray is a char[], so these should allocate. char[] a = myArray; char[] b = myArray; assert(a !is b); //This fails. It shouldn't. } //---- Such usage is used extensively throughout phobos. In particular, things like: enum someString = format(XXXXXXXXX); If this is not valid code, then I am *completely* lost. It turns out that when doing this, using "someString" will trigger an allocation on every use, which is contrary to the whole "string literals don't allocate". Unless I'm missing something, "someString" *is* a string literal, right? The second useage is rarer, but the consequences of the failure are more problematic (mutables referencing shared immutable data). I didn't fully understand 4397, but it does look like it's root issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
