Thread overview | ||||||||
---|---|---|---|---|---|---|---|---|
|
November 20, 2012 [Issue 9051] New: [CTFE] Working with non-trivial immutable globals? | ||||
---|---|---|---|---|
| ||||
http://d.puremagic.com/issues/show_bug.cgi?id=9051 Summary: [CTFE] Working with non-trivial immutable globals? Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody@puremagic.com ReportedBy: dmitry.olsh@gmail.com --- Comment #0 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2012-11-20 12:50:42 PST --- I'm wondering if this is supposed to work. By all means I don't see why it has to try this(this) in this case (and moreover fail). struct Set{ uint[] arr; this(this){ } //comment out to make it compile } pure auto getMeASet(uint[] arr) { return Set(arr); } immutable set = getMeASet([1,2,3,4]); pure auto getSecond(in Set set) { return set.arr[1]; } pragma(msg, getSecond(set)); And the diagnostic spits all kinds of nonsense: D:\D\ctfe_glob.d(20): Error: variable ctfe_glob.__cpcttmp6 of type struct const(Set) uses this(this), which is not allowed in static initialization D:\D\ctfe_glob.d(20): while evaluating pragma(msg, getSecond((const const(Set) __cpcttmp6 = Set([1u, 2u, 3u, 4u]); , __cpcttmp6))) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
November 21, 2012 [Issue 9051] Passing an immutable global with post-blit to a CTFE function | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | http://d.puremagic.com/issues/show_bug.cgi?id=9051 Don <clugdbug@yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |diagnostic Summary|[CTFE] Working with |Passing an immutable global |non-trivial immutable |with post-blit to a CTFE |globals? |function --- Comment #1 from Don <clugdbug@yahoo.com.au> 2012-11-21 02:13:04 PST --- The error message is not coming from CTFE. Here's a simple case from a comment in the compiler source code (declaration.c): /* The problem is the following code: * struct CopyTest { * double x; * this(double a) { x = a * 10.0;} * this(this) { x += 2.0; } * } * const CopyTest z = CopyTest(5.3); // ok * const CopyTest w = z; // not ok, postblit not run * static assert(w.x == 55.0); * because the postblit doesn't get run on the initialization of w. */ I think that if we didn't call this(this), wrong code would result. There is at least a diagnostic bug here - if it must behave this way, the code that creates the comma expression should be issuing the error. Interestingly, if you move it inside a function, the result is different: void foo() { pragma(msg, getSecond(set)); } qqq.d(19): Error: static variable set cannot be referenced at compile time qqq.d(19): called from here: __cpcttmp6.__cpctor(set) qqq.d(19): called from here: getSecond((const const(Set) __cpcttmp6 = __cpcttmp6.__cpctor(set); , __cpcttmp6)) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
November 21, 2012 [Issue 9051] Passing an immutable global with post-blit to a CTFE function | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | http://d.puremagic.com/issues/show_bug.cgi?id=9051 --- Comment #2 from Dmitry Olshansky <dmitry.olsh@gmail.com> 2012-11-21 10:49:17 PST --- (In reply to comment #1) > The error message is not coming from CTFE. Here's a simple case from a comment in the compiler source code (declaration.c): > > /* The problem is the following code: > * struct CopyTest { > * double x; > * this(double a) { x = a * 10.0;} > * this(this) { x += 2.0; } > * } > * const CopyTest z = CopyTest(5.3); // ok > * const CopyTest w = z; // not ok, postblit not run > * static assert(w.x == 55.0); > * because the postblit doesn't get run on the initialization of w. > */ > > I think that if we didn't call this(this), wrong code would result. I agree in general. And But given that getMeASet(uint[] arr) is an r-value. Surely the result of it should be just moved? The other thought is: can't this(this) be run at compile-time then? What are limitations? > There is at least a diagnostic bug here - if it must behave this way, the code that creates the comma expression should be issuing the error. > > Interestingly, if you move it inside a function, the result is different: > The same thing happens if you try passing set by reference be it const or otherwise. > void foo() > { > pragma(msg, getSecond(set)); > } > > qqq.d(19): Error: static variable set cannot be referenced at compile time > qqq.d(19): called from here: __cpcttmp6.__cpctor(set) > qqq.d(19): called from here: getSecond((const const(Set) __cpcttmp6 = > __cpcttmp6.__cpctor(set); > , __cpcttmp6)) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
November 26, 2012 [Issue 9051] Passing an immutable global with post-blit to a CTFE function | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dmitry Olshansky | http://d.puremagic.com/issues/show_bug.cgi?id=9051 --- Comment #3 from Don <clugdbug@yahoo.com.au> 2012-11-26 00:56:22 PST --- (In reply to comment #2) > (In reply to comment #1) > > The error message is not coming from CTFE. Here's a simple case from a comment in the compiler source code (declaration.c): > > > > /* The problem is the following code: > > * struct CopyTest { > > * double x; > > * this(double a) { x = a * 10.0;} > > * this(this) { x += 2.0; } > > * } > > * const CopyTest z = CopyTest(5.3); // ok > > * const CopyTest w = z; // not ok, postblit not run > > * static assert(w.x == 55.0); > > * because the postblit doesn't get run on the initialization of w. > > */ > > > > I think that if we didn't call this(this), wrong code would result. > > I agree in general. And But given that getMeASet(uint[] arr) is an r-value. Surely the result of it should be just moved? > > The other thought is: can't this(this) be run at compile-time then? What are > limitations? Yeah, that's kind of like bug 7988. The calling of this(this) should be part of the CTFE'd bit. CTFE could cope with it, no problem, it just doesn't get a chance. BTW if we moved the this(this) into CTFE, the example I posted would also work! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- |
Copyright © 1999-2021 by the D Language Foundation