Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Iterator next() is cloning the object and not allowing access to the iter object #12411

Open
jdonnerstag opened this issue Nov 8, 2021 · 2 comments
Labels
Bug This tag is applied to issues which reports bugs.

Comments

@jdonnerstag
Copy link
Contributor

jdonnerstag commented Nov 8, 2021

V version: V 0.2.4 52df19e
OS: windows, Microsoft Windows 10 Enterprise v19042 64-bit

What did you do?

struct MyIter {
mut:
	ar []int
	pos int
}

fn (mut m MyIter) next() ? int {
	for m.pos < m.ar.len {
		x := m.ar[m.pos]
		m.pos ++
		if x >= 5 { return x }
	}
	return error('')
}

type Intar = []int

fn (i Intar) my_filter() MyIter {
	return MyIter{ ar: i, pos: 0 }
}

fn test_iters() ? {
	data := Intar([1, 2, 5, 9, 3, 6, 0])
	//for x in data.filter() {	// conflicts with built-in filter() function
	for x in data.my_filter() {
		eprintln("x: $x")
	}

	mut iter := data.my_filter()
	for x in iter {
		eprintln("x: $x => $iter.pos")   // (1)
	}
}

What did you expect to see?
I expected to see that at (1) the updated pos value gets printed. Instead it is always the initial value. Which means that even in the 2nd test case (for x in iter {), V clones the object. And that means, I don't have access to it. And I think there is no way, to get access to the iter object that is being used by next().

What did you see instead?
At (1) always the initial value of pos is printed, but never the updated / real one.

@jdonnerstag jdonnerstag added the Bug This tag is applied to issues which reports bugs. label Nov 8, 2021
@jdonnerstag jdonnerstag changed the title Iterator next() is not cloning the object and not allowing access to the iter object Iterator next() is cloning the object and not allowing access to the iter object Nov 8, 2021
@jdonnerstag
Copy link
Contributor Author

The C-snippet confirms my understanding

	rosie__parser__rpl__Intar data = ((new_array_from_c_array(7, 7, sizeof(int), _MOV((int[7]){1, 2, 5, 9, 3, 6, 0}))));
	rosie__parser__rpl__MyIter _t1 = rosie__parser__rpl__Intar_my_filter(data);
	while (1) {
		Option_int _t2 = rosie__parser__rpl__MyIter_next(&_t1);
		if (_t2.state != 0) break;
		int x = *(int*)_t2.data;
		eprintln( str_intp(2, _MOV((StrIntpData[]){{_SLIT("x: "), 0xfe07, {.d_i32 = x}}, {_SLIT0, 0, { .d_c = 0 }}})));
	}
	rosie__parser__rpl__MyIter iter = rosie__parser__rpl__Intar_my_filter(data);
	rosie__parser__rpl__MyIter _t3 = iter;
	while (1) {
		Option_int _t4 = rosie__parser__rpl__MyIter_next(&_t3);

_t1 and _t3 are (internal) clones not access from V. At least in the 2nd example, _t3 is superfluous and not needed. V needs to detect that a variables has been declared already and leverage that, rather then making another copy.

@jdonnerstag
Copy link
Contributor Author

A workaround is not complicated, but it took me half a day to realise what is actually going wrong. Of course first I assumed I'm doing something wrong, until I figured it out. If properly supportting it is too complicated or cumbersome at first, then at least a useful warning or error message would be good.

mut iter := data.my_filter()
for {
    x := iter.next() or { break }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug This tag is applied to issues which reports bugs.
Projects
None yet
Development

No branches or pull requests

1 participant