digitalmars.D - Bug in the spec or implementation?
- simendsjo (11/11) Aug 05 2010 This is only tested on dmd 2.047 on win7.
- Steven Schveighoffer (9/20) Aug 05 2010 Concatenation is this:
- simendsjo (9/32) Aug 05 2010 Hmm... Doing "a = a ~ 1", and it works like specified.
- Steven Schveighoffer (20/59) Aug 05 2010 I found this line in the spec:
- simendsjo (21/41) Aug 05 2010 Thanks!
- Steven Schveighoffer (9/62) Aug 05 2010 Yep, I noticed that too when going to file the bug :)
- simendsjo (6/40) Aug 05 2010 Thanks again!
- Andrej Mitrovic (7/7) Aug 05 2010 I think I might have made a report about this already, under "setting
- Steven Schveighoffer (7/15) Aug 05 2010 Yes, it is the same problem, but I'd like to keep both open because mine...
- Don (5/54) Aug 06 2010 Rule of thumb:
This is only tested on dmd 2.047 on win7. According to the spec at http://digitalmars.com/d/2.0/arrays.html: "Concatenation always creates a copy of its operands, even if one of the operands is a 0 length array" But this doesn't seem like the case: auto a = [0]; auto oldPtr = a.ptr; assert(a.length == 1); assert(a.capacity == 3); a ~= 1; assert(a.ptr != oldPtr); // Fails - Still the same array
Aug 05 2010
On Thu, 05 Aug 2010 14:45:18 -0400, simendsjo <simen.endsjo pandavre.com> wrote:This is only tested on dmd 2.047 on win7. According to the spec at http://digitalmars.com/d/2.0/arrays.html: "Concatenation always creates a copy of its operands, even if one of the operands is a 0 length array" But this doesn't seem like the case: auto a = [0]; auto oldPtr = a.ptr; assert(a.length == 1); assert(a.capacity == 3); a ~= 1; assert(a.ptr != oldPtr); // Fails - Still the same arrayConcatenation is this: a ~ 1 appending is this: a ~= 1 Two separate operations, two separate semantics. It might not be easy to determine that from the spec, but I believe the spec is clear. -Steve
Aug 05 2010
On 05.08.2010 20:53, Steven Schveighoffer wrote:On Thu, 05 Aug 2010 14:45:18 -0400, simendsjo <simen.endsjo pandavre.com> wrote:Hmm... Doing "a = a ~ 1", and it works like specified. I always assumed that composite operators would mean the same.. That "a += 1" is the same as "a = a + 1" etc. I cannot find this behavior explained in the spec though.. From the Expression spec, I found that "a op= b" is the same as "a = a op b" - see "Assignment Operator Expressions". No mention of a CatAssignExpression behaving differently. Array doesn't mention anything either.This is only tested on dmd 2.047 on win7. According to the spec at http://digitalmars.com/d/2.0/arrays.html: "Concatenation always creates a copy of its operands, even if one of the operands is a 0 length array" But this doesn't seem like the case: auto a = [0]; auto oldPtr = a.ptr; assert(a.length == 1); assert(a.capacity == 3); a ~= 1; assert(a.ptr != oldPtr); // Fails - Still the same arrayConcatenation is this: a ~ 1 appending is this: a ~= 1 Two separate operations, two separate semantics. It might not be easy to determine that from the spec, but I believe the spec is clear. -Steve
Aug 05 2010
On Thu, 05 Aug 2010 15:13:26 -0400, simendsjo <simen.endsjo pandavre.com> wrote:On 05.08.2010 20:53, Steven Schveighoffer wrote:I found this line in the spec: "These issues also apply to concatenating arrays with the ~ and ~= operators." Where "These issues" refer to reallocating in place (look at the section for setting the length of an array). I think this line is in error, as it directly conflicts with the statement: "Concatenation always creates a copy of its operands, even if one of the operands is a 0 length array" I think the line should read: "These issues also apply to appending arrays with the ~= operator. Note that the concatenation operator ~ is not affected since it always reallocates." I can assure you that the runtime does always make a copy on concatenation, and always tries to append in place if possible on an expanding length or an append. The spec needs some work, but the runtime is correct. I will file a bug against the spec for you. -SteveOn Thu, 05 Aug 2010 14:45:18 -0400, simendsjo <simen.endsjo pandavre.com> wrote:Hmm... Doing "a = a ~ 1", and it works like specified. I always assumed that composite operators would mean the same.. That "a += 1" is the same as "a = a + 1" etc. I cannot find this behavior explained in the spec though.. From the Expression spec, I found that "a op= b" is the same as "a = a op b" - see "Assignment Operator Expressions". No mention of a CatAssignExpression behaving differently. Array doesn't mention anything either.This is only tested on dmd 2.047 on win7. According to the spec at http://digitalmars.com/d/2.0/arrays.html: "Concatenation always creates a copy of its operands, even if one of the operands is a 0 length array" But this doesn't seem like the case: auto a = [0]; auto oldPtr = a.ptr; assert(a.length == 1); assert(a.capacity == 3); a ~= 1; assert(a.ptr != oldPtr); // Fails - Still the same arrayConcatenation is this: a ~ 1 appending is this: a ~= 1 Two separate operations, two separate semantics. It might not be easy to determine that from the spec, but I believe the spec is clear. -Steve
Aug 05 2010
On 05.08.2010 21:41, Steven Schveighoffer wrote:On Thu, 05 Aug 2010 15:13:26 -0400, simendsjo <simen.endsjo pandavre.com> wrote: I found this line in the spec: "These issues also apply to concatenating arrays with the ~ and ~= operators." Where "These issues" refer to reallocating in place (look at the section for setting the length of an array). I think this line is in error, as it directly conflicts with the statement: "Concatenation always creates a copy of its operands, even if one of the operands is a 0 length array" I think the line should read: "These issues also apply to appending arrays with the ~= operator. Note that the concatenation operator ~ is not affected since it always reallocates." I can assure you that the runtime does always make a copy on concatenation, and always tries to append in place if possible on an expanding length or an append. The spec needs some work, but the runtime is correct. I will file a bug against the spec for you. -SteveThanks! Seems there are plenty of errors in the spec though... It will be very difficult to learn the language if the spec and implementation is different. Spec or compiler bug? char[] a = new char[20]; char[] b = a[0..10]; assert(a.ptr == b.ptr); // hmm.. does slice has a offset property or something? // In the spec on arrays#Setting Dynamic Array Length, // this is the example, but it doesn't work as in the spec... char[] c = a[10..20]; // The spec says expanding b.length should expand // in place as a has enough memory and thus overlapping a, but... assert(b.capacity == 0); // capacity is 0, so... b.length = 15; assert(b.capacity == 15); // .. setting length removed it from a.. assert(a.ptr == b.ptr); // fails... b[11] = 'x'; // Says a[11] and c[1] should also change.. assert(a[11] == 'x'); // fails assert(c[1] == 'x'); // fails
Aug 05 2010
On Thu, 05 Aug 2010 16:00:35 -0400, simendsjo <simen.endsjo pandavre.com> wrote:On 05.08.2010 21:41, Steven Schveighoffer wrote:Yep, I noticed that too when going to file the bug :) see here: http://d.puremagic.com/issues/show_bug.cgi?id=4590 I should take responsibility for not fixing this sooner since the runtime used to work this way, but does not since a patch I added in 2.041 or 2.042. Sorry. -SteveOn Thu, 05 Aug 2010 15:13:26 -0400, simendsjo <simen.endsjo pandavre.com> wrote: I found this line in the spec: "These issues also apply to concatenating arrays with the ~ and ~= operators." Where "These issues" refer to reallocating in place (look at the section for setting the length of an array). I think this line is in error, as it directly conflicts with the statement: "Concatenation always creates a copy of its operands, even if one of the operands is a 0 length array" I think the line should read: "These issues also apply to appending arrays with the ~= operator. Note that the concatenation operator ~ is not affected since it always reallocates." I can assure you that the runtime does always make a copy on concatenation, and always tries to append in place if possible on an expanding length or an append. The spec needs some work, but the runtime is correct. I will file a bug against the spec for you. -SteveThanks! Seems there are plenty of errors in the spec though... It will be very difficult to learn the language if the spec and implementation is different. Spec or compiler bug? char[] a = new char[20]; char[] b = a[0..10]; assert(a.ptr == b.ptr); // hmm.. does slice has a offset property or something? // In the spec on arrays#Setting Dynamic Array Length, // this is the example, but it doesn't work as in the spec... char[] c = a[10..20]; // The spec says expanding b.length should expand // in place as a has enough memory and thus overlapping a, but... assert(b.capacity == 0); // capacity is 0, so... b.length = 15; assert(b.capacity == 15); // .. setting length removed it from a.. assert(a.ptr == b.ptr); // fails... b[11] = 'x'; // Says a[11] and c[1] should also change.. assert(a[11] == 'x'); // fails assert(c[1] == 'x'); // fails
Aug 05 2010
On 05.08.2010 22:24, Steven Schveighoffer wrote:On Thu, 05 Aug 2010 16:00:35 -0400, simendsjo <simen.endsjo pandavre.com> wrote:(...)On 05.08.2010 21:41, Steven Schveighoffer wrote:Thanks again! Hope spec bugs have high priorities as it's difficult to learn the language otherwise. Are the compiler pretty stable, so I can assume most bugs are in the spec, or is it the other way around?Seems there are plenty of errors in the spec though... It will be very difficult to learn the language if the spec and implementation is different. Spec or compiler bug? char[] a = new char[20]; char[] b = a[0..10]; assert(a.ptr == b.ptr); // hmm.. does slice has a offset property or something? // In the spec on arrays#Setting Dynamic Array Length, // this is the example, but it doesn't work as in the spec... char[] c = a[10..20]; // The spec says expanding b.length should expand // in place as a has enough memory and thus overlapping a, but... assert(b.capacity == 0); // capacity is 0, so... b.length = 15; assert(b.capacity == 15); // .. setting length removed it from a.. assert(a.ptr == b.ptr); // fails... b[11] = 'x'; // Says a[11] and c[1] should also change.. assert(a[11] == 'x'); // fails assert(c[1] == 'x'); // failsYep, I noticed that too when going to file the bug :) see here: http://d.puremagic.com/issues/show_bug.cgi?id=4590 I should take responsibility for not fixing this sooner since the runtime used to work this way, but does not since a patch I added in 2.041 or 2.042. Sorry. -Steve
Aug 05 2010
I think I might have made a report about this already, under "setting dynamic array length" here http://d.puremagic.com/issues/show_bug.cgi?id=4551 . I didn't file it as a DMD bug, I've filed a bunch of stuff for the spec (as you can see in the other "D2 Language Docs" bug reports of mine), so I'm hoping sooner or later someone could take a look at those (I've also provided some fixes in there).
Aug 05 2010
On Thu, 05 Aug 2010 16:39:48 -0400, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:I think I might have made a report about this already, under "setting dynamic array length" here http://d.puremagic.com/issues/show_bug.cgi?id=4551 . I didn't file it as a DMD bug, I've filed a bunch of stuff for the spec (as you can see in the other "D2 Language Docs" bug reports of mine), so I'm hoping sooner or later someone could take a look at those (I've also provided some fixes in there).Yes, it is the same problem, but I'd like to keep both open because mine contains a fix for the spec, whereas yours just points out the problem (understandably). And it's not a dmd bug anyways, it's a spec bug. -Steve
Aug 05 2010
simendsjo wrote:On 05.08.2010 22:24, Steven Schveighoffer wrote:Rule of thumb: If the code compiles, but behaves differently to what the spec says, you can be pretty sure it's a spec bug. If the spec says it should work, but the compiler rejects it, it's most likely a compiler bug.On Thu, 05 Aug 2010 16:00:35 -0400, simendsjo <simen.endsjo pandavre.com> wrote:(...)On 05.08.2010 21:41, Steven Schveighoffer wrote:Thanks again! Hope spec bugs have high priorities as it's difficult to learn the language otherwise. Are the compiler pretty stable, so I can assume most bugs are in the spec, or is it the other way around?Seems there are plenty of errors in the spec though... It will be very difficult to learn the language if the spec and implementation is different. Spec or compiler bug? char[] a = new char[20]; char[] b = a[0..10]; assert(a.ptr == b.ptr); // hmm.. does slice has a offset property or something? // In the spec on arrays#Setting Dynamic Array Length, // this is the example, but it doesn't work as in the spec... char[] c = a[10..20]; // The spec says expanding b.length should expand // in place as a has enough memory and thus overlapping a, but... assert(b.capacity == 0); // capacity is 0, so... b.length = 15; assert(b.capacity == 15); // .. setting length removed it from a.. assert(a.ptr == b.ptr); // fails... b[11] = 'x'; // Says a[11] and c[1] should also change.. assert(a[11] == 'x'); // fails assert(c[1] == 'x'); // failsYep, I noticed that too when going to file the bug :) see here: http://d.puremagic.com/issues/show_bug.cgi?id=4590 I should take responsibility for not fixing this sooner since the runtime used to work this way, but does not since a patch I added in 2.041 or 2.042. Sorry. -Steve
Aug 06 2010