digitalmars.D.learn - nogc inconsistent for array comparison depending on mutability of
- rcorre (9/9) Apr 07 2016 @nogc unittest {
- Xinok (13/22) Apr 07 2016 Semantically, array literals are always allocated on the heap. In
- Nick Treleaven (6/21) Apr 08 2016 So @nogc is enforced by the optimizer?
- Rene Zwanenburg (5/9) Apr 08 2016 equal[1] can compare ranges of different types. It's a bit less
- Nick Treleaven (4/14) Apr 08 2016 opEquals would too. Not sure what you're saying. It wouldn't
- Dicebot (4/8) Apr 08 2016 Yes, sadly. To make it sane one would need to make a list of all
nogc unittest { int[2] a = [1, 2]; assert(a == [1, 2]); // OK immutable(int)[2] b = [1, 2]; assert(b == [1, 2]); // fail: array literal may cause allocation } Is there any logic behind allowing the comparison with `a` but not `b`, or is this a compiler bug?
Apr 07 2016
On Friday, 8 April 2016 at 01:36:18 UTC, rcorre wrote:nogc unittest { int[2] a = [1, 2]; assert(a == [1, 2]); // OK immutable(int)[2] b = [1, 2]; assert(b == [1, 2]); // fail: array literal may cause allocation } Is there any logic behind allowing the comparison with `a` but not `b`, or is this a compiler bug?Semantically, array literals are always allocated on the heap. In this case, the optimizer can obviously place the array on the stack or even make it static/global. However, it would be in poor design to rely on the optimizer to satisfy nogc. It comes down to portability; if the code compiles successfully with one compiler, then it should compile successfully in any other compiler. Also, the way that compilers are typically built is that semantic analysis is done in the frontend and optimization is done in the backend. Trying to build a bridge between these two would be incredibly difficult and make implementing the compiler much more complex with little gain.
Apr 07 2016
On Friday, 8 April 2016 at 03:14:40 UTC, Xinok wrote:On Friday, 8 April 2016 at 01:36:18 UTC, rcorre wrote:So nogc is enforced by the optimizer? If the comparison with b shouldn't be allowed, I suggest we add opEquals to std.range.only. This removes a need to import std.algorithm.equal and reduces bracket nesting: assert(b == only(1, 2));nogc unittest { int[2] a = [1, 2]; assert(a == [1, 2]); // OK immutable(int)[2] b = [1, 2]; assert(b == [1, 2]); // fail: array literal may cause allocation } Is there any logic behind allowing the comparison with `a` but not `b`, or is this a compiler bug?Semantically, array literals are always allocated on the heap. In this case, the optimizer can obviously place the array on the stack or even make it static/global.
Apr 08 2016
On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote:If the comparison with b shouldn't be allowed, I suggest we add opEquals to std.range.only. This removes a need to import std.algorithm.equal and reduces bracket nesting: assert(b == only(1, 2));equal[1] can compare ranges of different types. It's a bit less clear than the original code though. b.equal(only(1, 2));
Apr 08 2016
On Friday, 8 April 2016 at 10:11:43 UTC, Rene Zwanenburg wrote:On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote:opEquals would too. Not sure what you're saying. It wouldn't replace equal, only equal(only()). Pun intended.If the comparison with b shouldn't be allowed, I suggest we add opEquals to std.range.only. This removes a need to import std.algorithm.equal and reduces bracket nesting: assert(b == only(1, 2));equal[1] can compare ranges of different types.It's a bit less clear than the original code though. b.equal(only(1, 2));I'd argue the opposite.
Apr 08 2016
On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote:Yes, sadly. To make it sane one would need to make a list of all optimization DMD makes in that regard and put them into spec as mandatory for all compilers.Semantically, array literals are always allocated on the heap. In this case, the optimizer can obviously place the array on the stack or even make it static/global.So nogc is enforced by the optimizer?
Apr 08 2016
On Friday, 8 April 2016 at 10:15:10 UTC, Dicebot wrote:On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote:What? O_o I stated that it's not and explained why doing so would be a bad idea.Yes, sadly.Semantically, array literals are always allocated on the heap. In this case, the optimizer can obviously place the array on the stack or even make it static/global.So nogc is enforced by the optimizer?To make it sane one would need to make a list of all optimization DMD makes in that regard and put them into spec as mandatory for all compilers.
Apr 08 2016
On Friday, 8 April 2016 at 12:45:59 UTC, Xinok wrote:On Friday, 8 April 2016 at 10:15:10 UTC, Dicebot wrote:It is not enforced by _backend_ optimizer as all relevant checks are done by frontend but the fact of will you get error or not does depend on semantics that are currently defined as optional optimizations. Like putting array literal on stack.On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote:What? O_o I stated that it's not and explained why doing so would be a bad idea.Yes, sadly.Semantically, array literals are always allocated on the heap. In this case, the optimizer can obviously place the array on the stack or even make it static/global.So nogc is enforced by the optimizer?
Apr 08 2016