How should V handle autogenerated methods/functions?

[spytheman]

Some methods like .index and .contains are autogenerated during cgen, and not present in source code form.
This presents a discoverability problem, because tooling like v doc builtin and vls (which work over the AST, before it is passed to cgen) will not see them, and thus not produce information about them.

How should V handle this problem?

[danieldaeschle]

is contains a method which will be used anywhere or is it just the functionality behind in?

[danieldaeschle]

If it will be used in real code, what's against defining it in builtin/vlib?

[spytheman]

Defining it with source will be better, but will require generics to work and to be available for use in builtin too.

[danieldaeschle]

That will never work what @medvednikov said. Because of cached modules.

[yuyi98]

I think that we can define attr just like [auto_gen_function] to process this problem.

[auto_gen_function]
pub fn (a []T) insert(i int, v T)
...

[spytheman]

If generics worked, there would not be a need for custom generating these in the codegen stage.

[larpon]

... or use a simple hardcoded list I don't think there's many of these?

[danieldaeschle]

We can also add methods to the table manually when creation the table.

[JalonSolov]

Hard-coded == bad. Always. Maybe not right away, but unless it's a Universal Constant (like PI, or Avogadro's Number, etc.), nothing should ever be hard-coded in software.

It doesn't take that much extra effort to make it more flexible, then you never have to worry about it again.