WNDCLASSA structure is uncompileable.

[eLeCtrOssSnake]

Creating a window requires using WNDCLASSA structure. Zig does not permit an extern structure to have a fn ptr type. Although it is unclear why Zig considers that an issue, it makes it impossible to interact with this api.

ERROR:

zigwin32\win32\ui\windows_and_messaging.zig:4704:5: error: extern structs cannot contain fields of type 
'?fn(*win32.foundation.HWND, u32, usize, isize) callconv(.C) isize'
    lpfnWndProc: ?WNDPROC,
    ^~~~~~~~~~~~~~~~~~~~~
C:\stuff\zig_testground\1-1\deps\zigwin32\win32\ui\windows_and_messaging.zig:4704:5: note: only pointer like optionals are extern compatible

[marler8997]

I think this is an issue with how the new zig compiler treats function pointers differently. What's the version of your compiler? (output of zig version)? We'll probably want to update how we generate function pointer types to accommodate both kinds.

[eLeCtrOssSnake]

My zig version is: 0.10.0-dev.3871+b7d5582de I've asked for help on #zig IRC and was told that new behaviour for this should include const fn pointers rather than fn.

[marler8997]

Yeah, your compiler is new enough to be using the new features. I'll need to go in and modify the code generator to use *const fn like you mentioned (I can use an if to use the old definition to continue supporting the stage1 compiler as well).

[eLeCtrOssSnake]

Honestly surprised by such unexpected and breaking change. I wonder why this breaking change was justified, as it doesnt bring anything in terms of features.

Andrewk did say: 23:18:24 <andrewrk> electrosssnake, it's for consistency 23:18:57 <andrewrk> and simplicity. I like not having to remember a lot of exceptions to rules

But in my opinion there are other things to worry about.

[marler8997]

Older more established languages need to balance between improvements and code breakage, Zig's not at that stage yet, so, as long as something is deemed to be an improvement then it needs no justification above that. The hard part is analyzing whether changes are actually improvements. Zig's zen is very good to remember and keep in mind, also when working on your own applications :)

[eLeCtrOssSnake]

Thats what my question was about. Was it even an improvement.

[marler8997]

That's a good question to ask. I don't really know the answer myself though :)

In any case, I've created a PR where I'm implementing the fix here: https://github.com/marlersoft/zigwin32gen/pull/17/files

[marler8997]

Fix is integrated: https://github.com/marlersoft/zigwin32/commit/ff6245cda42adc6c3494bc4d8a5aaaa83c106e30

[tauoverpi]

Thats what my question was about. Was it even an improvement.

It allows you to forward the location of the function at compile-time such that you end up with the equivalent of directly calling the function allowing the compiler to generate call instead of a call_indirect. That would improvement in cases where you'd otherwise have to pass a function pointer even when you statically know which function you'll call and makes it possible to express intent more clearly (assumption).

[eLeCtrOssSnake]

Thats what my question was about. Was it even an improvement.

It allows you to forward the location of the function at compile-time such that you end up with the equivalent of directly calling the function allowing the compiler to generate call instead of a call_indirect. That would improvement in cases where you'd otherwise have to pass a function pointer even when you statically know which function you'll call and makes it possible to express intent more clearly (assumption).

Just as longer it doesn't remove any non const fn ptr functionality then it is an improvement.

[marler8997]

Interesting. Wouldn't you have been able to do that before though by adding comptime to the function pointer parameter? i.e. comptime f: fn(...)

As I think on it more, this change is interesting because it moves the concept of comptime into the type itself. I can't think of any other type that behaves like this. Still unsure whether it's an improvement or not, I just find it interesting and am curious to hear more about it.