non-optional variants of C pointers

[Rageoholic]

So in several cases when interacting with C code a function pointer has been typedef'd so that the pointer is part of the type such as typedef void (VKAPI_PTR *PFN_vkVoidFunction)(void);. In usage I would prefer to unwrap these as early as possible and never unwrap them again, however if I do that I have to make my own type aliases for these functions. Would it be possible to take a C typedef'd pointer type and add some syntactic sugar to say that it is not optional and cannot be null.

[JesseRMeyer]

How would you handle of the case of the vulkan (or GL, say) driver not supplying a function you want, say, because it's an old or broken implementation? Maybe I misunderstand the exact scenario, but isn't unwrapping what you want here at the interface layer between C and Zig?

[Rageoholic]

a) this was hypothetical, there are many situations where you are guaranteed by the library that a return value or an out parameter will be non-null b) I am assuming a functional driver (dangerous I know) Also I am moving extensions into their own structs that would be unwrapped in the manner specified because they can be absent.

…

On Fri, Jan 10, 2020 at 7:43 AM Jesse Meyer ***@***.***> wrote: How would you handle of the case of the vulkan (or GL, say) driver not supplying a function you want, say, because it's an old or broken implementation? Maybe I misunderstand the exact scenario, but isn't unwrapping what you want here at the interface layer between C and Zig? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4127?email_source=notifications&email_token=ACC47ZPNXTDWT3TYIPUYTYTQ5B3P5A5CNFSM4KFAMHIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIT6NNI#issuecomment-573040309>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACC47ZPFVSFTSP3URPCCOCTQ5B3P5ANCNFSM4KFAMHIA> .

[JesseRMeyer]

Ah, are you suggesting a function pointer type that automatically unwraps only once only during assignment? I think it's dangerous to assume that the pointer value from C code is valid, even if the source is spec'd to be valid. But if the claim can be demonstrated to be valid (the unwrap in Zig code), then Zig pointer semantics are preserved at the interface boundary without leaks.

[Rageoholic]

Yeah I just want to give a name to something you use with a pattern like ``` //in C code typedef struct x *opaque_type; opaque_type foo(); //in zig const Foo = struct { bar : unwrapped_opaque_type, } ... Foo{.bar = foo().?} ``` But unwrapped_opaque_type is autogenerated so you don't have to name it yourself. Not just for function pointers.

…

On Fri, Jan 10, 2020 at 8:20 AM Jesse Meyer ***@***.***> wrote: Ah, are you suggesting a function pointer type that automatically unwraps *only once* only during assignment? I think it's dangerous to assume that the pointer value from C code is valid, even if the source is spec'd to be valid. But if the claim can be demonstrated to be valid (the unwrap in Zig code), then Zig pointer semantics are preserved at the interface boundary without leaks. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4127?email_source=notifications&email_token=ACC47ZIJJ3DH6UN434KXA33Q5B74JA5CNFSM4KFAMHIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIUBYLA#issuecomment-573053996>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACC47ZKROCW4RPEGTQYPL6DQ5B74JANCNFSM4KFAMHIA> .

[kristoff-it]

Unless I misunderstand, this seems part of what is being discussed in #2457.
If we get @reify (#2907) this should be possible to implement as a library.

[daurnimator]

I think I've mentioned it somewhere before, but I think that [*c] should become non-optional: gaining the meaning "not sure if single or multiple item pointer". A C pointer defined using the nonnull GCC attribute would be able to be converted to this. Most C pointers would end but being translated to ?[*c].