Re: @nogc inconsistent for array comparison depending on mutability of elements
On Friday, 8 April 2016 at 12:45:59 UTC, Xinok wrote: 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: 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? Yes, sadly. What? O_o I stated that it's not and explained why doing so would be a bad idea. 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.
Re: @nogc inconsistent for array comparison depending on mutability of elements
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: 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? Yes, sadly. What? O_o I stated that it's not and explained why doing so would be a bad idea. 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.
Re: @nogc inconsistent for array comparison depending on mutability of elements
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: 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. opEquals would too. Not sure what you're saying. It wouldn't replace equal, only equal(only()). Pun intended. It's a bit less clear than the original code though. b.equal(only(1, 2)); I'd argue the opposite. [1] http://dlang.org/phobos/std_algorithm_comparison.html#.equal
Re: @nogc inconsistent for array comparison depending on mutability of elements
On Friday, 8 April 2016 at 09:56:41 UTC, Nick Treleaven wrote: 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? 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.
Re: @nogc inconsistent for array comparison depending on mutability of elements
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)); [1] http://dlang.org/phobos/std_algorithm_comparison.html#.equal
Re: @nogc inconsistent for array comparison depending on mutability of elements
On Friday, 8 April 2016 at 03:14:40 UTC, Xinok wrote:
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.
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));
Re: @nogc inconsistent for array comparison depending on mutability of elements
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.
@nogc inconsistent for array comparison depending on mutability of elements
@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?
