digitalmars.D.learn - T[] opIndex() Error: .. signal 11
- Joel (54/54) Oct 03 2023 The following program crashes, but doesn’t if I change (see
- ryuukk_ (16/70) Oct 03 2023 Remove:
- Steven Schveighoffer (84/87) Oct 03 2023 It's a stack overflow.
- Paul Backus (12/30) Oct 03 2023 Naturally, this lowering is completely absent from [the language
- ag0aep6g (3/13) Oct 04 2023 For some further reading, there's an open issue about the unexpected
- Steven Schveighoffer (3/5) Oct 05 2023 Thank you I had forgotten about that issue!
The following program crashes, but doesn’t if I change (see title) T[] to auto. The program doesn’t even use that method/function. What’s the story? ```d // Adding program - literal functions import std; struct List(T) { class Node { T data; Node next; this(T data) { this.data=data; } } string title; size_t length; Node head; this(string title, T[] data...) { this.title=title; length=data.length; if (length) { head=new Node(data[0]); auto cur=head; data[1..$].each!((d) { cur.next=new Node(d); cur=cur.next; }); } } bool empty() { return head is null; } auto ref front() { return head.data; } void popFront() { head=head.next; } T[] opIndex() { return this.array; } auto opDollar() { return length; } } void main(string[] args) { args.popFront; List!int ints; if (args.length) { ints=List!int(args[0], args[1..$].to!(int[])); } else{ ints=List!int("Car, and Date numbers", 1979,9,3,4,5); } stdout.write(ints.title, ": "); ints.each!((i, d) { stdout.write(d, i+1<ints.length ? "+" : "="); }); writeln(ints.sum); } ```
Oct 03 2023
On Tuesday, 3 October 2023 at 15:12:34 UTC, Joel wrote:The following program crashes, but doesn’t if I change (see title) T[] to auto. The program doesn’t even use that method/function. What’s the story? ```d // Adding program - literal functions import std; struct List(T) { class Node { T data; Node next; this(T data) { this.data=data; } } string title; size_t length; Node head; this(string title, T[] data...) { this.title=title; length=data.length; if (length) { head=new Node(data[0]); auto cur=head; data[1..$].each!((d) { cur.next=new Node(d); cur=cur.next; }); } } bool empty() { return head is null; } auto ref front() { return head.data; } void popFront() { head=head.next; } T[] opIndex() { return this.array; } auto opDollar() { return length; } } void main(string[] args) { args.popFront; List!int ints; if (args.length) { ints=List!int(args[0], args[1..$].to!(int[])); } else{ ints=List!int("Car, and Date numbers", 1979,9,3,4,5); } stdout.write(ints.title, ": "); ints.each!((i, d) { stdout.write(d, i+1<ints.length ? "+" : "="); }); writeln(ints.sum); } ```Remove: It didn't segfault for me, but it still didn't print what's in the ``ints``, but if you remove the following code: ``` T[] opIndex() { return this.array; } auto opDollar() { return length; } ``` ..then it'll work Sounds like a bug.. i don't use these D features, maybe someone else have more insights? Either way, what a terrible experience
Oct 03 2023
On 10/3/23 11:12 AM, Joel wrote:The following program crashes, but doesn’t if I change (see title) T[] to auto. The program doesn’t even use that method/function. What’s the story?It's a stack overflow. when doing foreach on your type, the compiler *always* uses a slice first if it compiles and is a valid range. So `foreach(x; ints)` really translates to `foreach(x; ints[])`. Normally not a problem. But your `opIndex()` is calling `this.array`. What does `this.array` do? a foreach on your type. Which calls `opIndex`, which calls `array`, which calls `opIndex`, etc. When you make it auto, well, then inside the `array` function, it won't use the `opIndex` (because clearly, the type hasn't been determined). And so it goes with the range functions without first doing a slice. But then outside the type, now that `opIndex` type has been inferred, it can now use `foreach(x; ints[])`, and that goes back to the regular mechanism. A minimized case is here: ```d struct S { int front() => 1; void popFront() {} bool empty() => true; auto opIndex() { foreach(x; this) {} return int[].init; } } void main() { S s; foreach(x; s) {} } ``` If you run this on run.dlang.io, and click the "AST" button, you will get this for the type and the main function: ```d import object; struct S { int front() { return 1; } void popFront() { } bool empty() { return true; } auto system int[] opIndex() { { S __r2 = this; for (; !__r2.empty(); __r2.popFront()) { int x = __r2.front(); } } return null; } } void main() { S s = 0; { scope int[] __r3 = s.opIndex()[]; ulong __key4 = 0LU; for (; __key4 < __r3.length; __key4 += 1LU) { int x = __r3[__key4]; } } return 0; } ``` Note the difference in how the foreach code is lowered. Inside `opIndex`, it's lowered to the range functions. Outside, it uses the slice operator to switch to iterating a `scope int[]`. If you now switch the `auto` to `int[]`, it's a segfault, because now the `opIndex` has a concrete return type, and it *can* use the `opIndex`, inside `opIndex`. I really think the implicit slice should be revisited. It shouldn't happen in this case. -Steve
Oct 03 2023
On Tuesday, 3 October 2023 at 17:05:46 UTC, Steven Schveighoffer wrote:```d void main() { S s = 0; { scope int[] __r3 = s.opIndex()[]; ulong __key4 = 0LU; for (; __key4 < __r3.length; __key4 += 1LU) { int x = __r3[__key4]; } } return 0; } ``` Note the difference in how the foreach code is lowered. Inside `opIndex`, it's lowered to the range functions. Outside, it uses the slice operator to switch to iterating a `scope int[]`.Naturally, this lowering is completely absent from [the language spec's section on `foreach`.][1] According to the spec, the only ways to iterate over a `struct` type are `opApply` and the input range interface. I think it would probably be less confusing to have both `opApply` and `empty`/`front`/`popFront` take precedence over this lowering, but I have no idea how much existing code would be broken by such a change. At the very least, though, this needs to be documented. [1]: https://dlang.org/spec/statement.html#foreach-statement
Oct 03 2023
On 03.10.23 20:26, Paul Backus wrote:Naturally, this lowering is completely absent from [the language spec's section on `foreach`.][1] According to the spec, the only ways to iterate over a `struct` type are `opApply` and the input range interface. I think it would probably be less confusing to have both `opApply` and `empty`/`front`/`popFront` take precedence over this lowering, but I have no idea how much existing code would be broken by such a change. At the very least, though, this needs to be documented. [1]: https://dlang.org/spec/statement.html#foreach-statementFor some further reading, there's an open issue about the unexpected slicing: https://issues.dlang.org/show_bug.cgi?id=14619
Oct 04 2023
On 10/5/23 1:49 AM, ag0aep6g wrote:For some further reading, there's an open issue about the unexpected slicing: https://issues.dlang.org/show_bug.cgi?id=14619Thank you I had forgotten about that issue! -Steve
Oct 05 2023