v icon indicating copy to clipboard operation
v copied to clipboard

generic higher order functions can only be instantiated once

Open spiveeworks opened this issue 2 years ago • 0 comments

Describe the bug

When defining higher order functions with a generic type parameter, the first instance of the higher order function works fine, but subsequent instances get confused what type they should expect.

Reproduction Steps

pub type MyFn[T] = fn (mut my_state T)

fn higher_order_fn[T](initial_state T, callback MyFn[T]) T {
    mut my_state := initial_state

    callback[T](mut my_state)
    callback[T](mut my_state)

    return my_state
}

pub struct Stateless { }

pub fn higher_order_fn_stateless(callback MyFn[Stateless]) {
    initial_state := Stateless { }
    higher_order_fn[Stateless](initial_state, callback)
}

pub struct State {
mut:
    x int
}

fn handler(mut my_state State) {
    my_state.x += 1
}

fn main() {
    initial_state := State { }
    new_state := higher_order_fn[State](initial_state, handler)
    println("${new_state}")
}

Expected Behavior

The program should compile and run fine, as if higher_order_fn_stateless were never defined.

Current Behavior

higher_order_fn_error1.v:30:56: error: cannot use `fn (mut State)` as `fn (mut Stateless)` in argument 2 to `higher_order_fn`
   28 | fn main() {
   29 |     initial_state := State { }
   30 |     new_state := higher_order_fn[State](initial_state, handler)
      |                                                        ~~~~~~~
   31 |     println("${new_state}")
   32 | }

Possible Solution

It works fine if you remove higher_order_fn_stateless.

Additional Information/Context

I discovered this by trying to make a little wrapper around gg that handles the logic associated with new_streaming_image and update_pixel_data automatically, so that multiple apps could simply write to the image given to them, and have a working app. Some of these apps didn't have any state, so I wanted to make a simpler version of start_app that just took callbacks without worrying about defining a different dummy state datastructure for each stateless app.

V version

V 0.4.5 ad17be5

Environment details (OS name and version, etc.)

V full version: V 0.4.5 386bd77.ad17be5 OS: windows, Microsoft Windows 10 Pro v19045 64-bit Processor: 4 cpus, 64bit, little endian,

getwd: C:\Users\Owner\Code\v-experiments vexe: C:\Program Files\v\v.exe vexe mtime: 2024-04-07 05:22:56

vroot: contains spaces, value: C:\Program Files\v VMODULES: OK, value: C:\Users\Owner.vmodules VTMP: OK, value: C:\Users\Owner\AppData\Local\Temp\v_0

Git version: git version 2.37.2.windows.2 Git vroot status: weekly.2024.14-26-gad17be5d (6 commit(s) behind V master) .git/config present: true

CC version: Error: 'cc' is not recognized as an internal or external command, operable program or batch file.

thirdparty/tcc: N/A

[!NOTE] You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote. Other reactions and those to comments will not be taken into account.

spiveeworks avatar Apr 07 '24 07:04 spiveeworks