confusion with compiletime $for iter var scoping

[choltreppe]

Hi all,
Im completly new to V, just found it yesterday. Im currently writing my first V program.
And I have a little question about comptime for + type introspection.

So I want to generate some code for every field of a struct. I tried this:

mut search_inputs := []gui.View{}
mut i := u32(1)
$for field in SearchPart.fields {
    search_inputs << gui.text(text: "${field.name}:")
    search_inputs << gui.input(
	    id_focus: i
	    text: app.search.$(field.name)
	    width: 200
	    sizing: gui.fixed_fit
	    on_text_changed: fn (_ &gui.InputCfg, s string, mut w gui.Window) {
		    mut state := w.state[App]()
		    state.search.$(field.name) = s
	    }
    )
    i += 1
}

but I get this error:

error: expected `string` instead of `void` (e.g. `field.name`)
 |  on_text_changed: fn (_ &gui.InputCfg, s string, mut w gui.Window) {
 |          mut state := w.state[App]()
 |          state.search.$(field.name) = s
 |                           ~~~~
 |      }
 |  )

so I suspect the problem is that on_text_changed closure needs to capture field.
But why? As far as I understand it field is a comptime var and gets baked info the resulting unrolled for loop. So why should field need to be captured by the closure?
what am I missing?

thanks in advance,
chol

[JalonSolov]

The V docs, when talking about closures inheriting variables from the scope they're in, say They must do so explicitly by listing all variables that are inherited. The closure is not allowed to see anything it doesn't explicitly inherit.

It also says Inherited variables are copied when the anonymous function is created. This means that if the original variable is modified after the creation of the function, the modification won't be reflected in the function.

This behavior has nothing to do with whether or not the closure is inside a comptime scope - the rules still apply, regardless.

[choltreppe]

ok, I still dont realy understand why that also applies to comptime vars but I probably misunderstand what comptime fors do.
my understanding of a comptime for: the for loop gets unrolled at compiletime, injecting code for every iteration with the iterations for-vars (field in my case) value replaced/baked-in as a literal value.
so why does the closure need to capture that variable if it doesnt even exist anymore at runtime and is just written into the final code as the literal value ?

sorry for pressing this so much, I just really want to understand.

anyways, I tried to capture field but its always the first field of the struct for every itteration. So I added a println of the field name and the whole structs state after the assignment to check:

...
    on_text_changed: fn [field] (_ &gui.InputCfg, s string, mut w gui.Window) {
		mut state := w.state[App]()
		state.search.$(field.name) = s
		println("${field.name}")
		println(state.search)
	}
...

and the result confused me even more. If I type 'x' into a field of search called manufacturer I get this on the console:

manufacturer
SearchPart{
    part: 'x'
    manufacturer: ''
    movement: ''
}

so apperently for the println("${field.name}") it captured the correct field but for state.search.$(field.name) = s it captured the first field (part)

what is happening?

[jorgeluismireles]

I don't know how to register a function to update a variable by calling state.search.$(field.name) = s but at least you can't be sure this variable is a string to start with, at least you need to add more checking like this:

struct Str {
	f int = 1
	s string
}

fn set_strings[T](mut t T, value string) {
	$if T is $struct {
		$for field in T.fields {
			$if field is string {
				t.$(field.name) = value
			}
		}
	}
}

fn main() {
	mut s := Str{}
	assert s.s == ''
	set_strings(mut s, 'default')
	assert s.s == 'default'
}

Seems to me you need to register apart in another generic function your on_text_changed callback iterating again the fields and checking types and names to update the correct field after the callback from the gui.

[choltreppe]

yes, but I know that all my fields are strings.

I think I didnt realy communicate what my problem/confusion is that well,
so here a bit more detailed

So SearchPart is defined as follows:

struct SearchPart {
mut:
  part string
  manufacturer string
  movement string
}

And I thought this code (bit shortened from my real code to focus on essential point):

$for field in SearchPart.fields {
  search_inputs << gui.text(text: "${field.name}:")
  search_inputs << gui.input(
    text: app.search.$(field.name)
    on_text_changed: fn (_ &gui.InputCfg, s string, mut w gui.Window) {
      mut state := w.state[App]()
      state.search.$(field.name) = s
    }
  )
}

would let the compiler transform this into:

search_inputs << gui.text(text: "part:")
search_inputs << gui.input(
  text: app.search.part
  on_text_changed: fn (_ &gui.InputCfg, s string, mut w gui.Window) {
    mut state := w.state[App]()
    state.search.part = s
  }
)
search_inputs << gui.text(text: "manufacturer:")
search_inputs << gui.input(
  text: app.search.manufacturer
  on_text_changed: fn (_ &gui.InputCfg, s string, mut w gui.Window) {
    mut state := w.state[App]()
    state.search.manufacturer = s
  }
)
search_inputs << gui.text(text: "movement:")
search_inputs << gui.input(
  text: app.search.movement
  on_text_changed: fn (_ &gui.InputCfg, s string, mut w gui.Window) {
    mut state := w.state[App]()
    state.search.movement = s
  }
)

completly unrolled and hardcoded into the result, so no need to capture and no need to loop through the fields inside the closure.
So I guess $for is not unrolling but if so what makes it different to a normal for then?

btw. I tested to write the unrolled version by hand, so I know there isnt another logic bug in the code.

[jorgeluismireles]

yes, but I know that all my fields are strings.

Just and idea, next code is pseudocode. Replace your struct elements by a map and pass to your gui functions the references to read the keys and write the values of the map:

type Search = map[string]string

fn new_search(fields ...string) Search {
	mut m := map[string]string
	for f in fields {
		m[f] = ''
	}
	return Search(m)
}

fn (mut search Search) register(mut inputs []gui.Input) {
	for k, _  in search {
		inputs << gui.text(text: '${k}:')
		inputs << gui.input(
			text: '${k}'
			on_text_changed: fn[mut search, k](_ &gui.InputCfg, s string, mut w gui.Window) {
				search[k] = s
			}
		)
	}
}

fn main() {
	search := new_search('part', 'manufacturer', 'movement')
	search.register(inputs)
}

This does not need compile time and I think the search[k] = s gui change will take effect in the map data.

[choltreppe]

I dont realy want to use a map for something that has a fixed comptime known set of fields, that just feels wrong.

Well I have a solution to mitigate my problem now, but I dont realy like it (because its not the way how the gui lib intends to be used and well its unsafe)

	$for field in SearchPart.fields {
		field_rt := &app.search.$(field.name)
		search_inputs << gui.text(text: "${field.name}:")
		search_inputs << gui.input(
			text: app.search.$(field.name)
			on_text_changed: fn [field_rt] (_ &gui.InputCfg, s string, mut w gui.Window) {
				unsafe {
					*field_rt = s
				}
			}
		)
	}

I also did look at some generated c code of some small test code, and I think I understand whats happening now.
The for loop gets unrolled, and the field var does get baked into the code (while still existing as a variable in c aswell). And it did bake the value into the closure body aswell. the only problem is. the closure generation magic stuff is generated for every iteration of the loop, but the function behind the closure is only generated once for the first iteration and used for every closure. (so its always mutating the first field)
Im about 80% sure this is a bug. If I feel the same tomorrow morning, Ill file an issue

PS: sorry for kinda ignoring your anwers and basicaly having a monologue about my findings. I just wasnt realy searching for a workaround but for an answer for why the code I wrote doesnt do what I think it should do

anyways Ill close the thread now