proposal: rename c_void to anyopaque

[AndreaOrru]

pub fn main() -> %void {
    var x: usize = 0x1000;
    var y: &void = @intToPtr(&void, x);
}

This causes the compiler to segfault.

[thejoshwolfe]

the segfault is for sure a bug. the expected behavior is that you get a compile error that usize and &void do not have the same number of bits. 64 != 0 (or similar).

you may already know the following, but i like bringing up this stuff whenever i can in case someone has some insights on it:

In Zig, a pointer to anything suggests that you're going to follow the pointer rather than do pointer arithmetic. following a pointer to void always results in the same value: {}, which means we don't need any bits to keep track of that behavior. So a pointer to void is also effectively void, in the sense that they're both 0-bit types.

A 0-length fixed-size array of anything is also a 0-bit type, since you can't do anything with it.

A slice of voids is allowed, and not quite a 0-bit type. A slice is {.ptr, .len}, and the .ptr is a 0-bit &void, but the .len is a real usize.

In general:

• void is a 0-bit type.
• a pointer to a 0-bit type is also a 0-bit type.
• @sizeOf([N]T) == N * @sizeOf(T) (except for any bitpacking optimizations).
• []T is effectively​ struct {ptr: &T, len: usize}.

[andrewrk]

I added a compile error for @intToPtr with a 0-bit pointer.

Alternatives to where you would use void* in C are:

• usize
• &u8
• &c_void

Currently c_void exists for compatibility with C libraries, and the c_ prefix hints that you shouldn't need to use it unless you're interacting with C code.

@thejoshwolfe what do you think about promoting the concept of an opaque pointer to zig land? So we would rename c_void to opaque or something like that, and then it would be acceptable to use it in zig land. Maybe then instead of @OpaqueType() (which I didn't implement yet) it could be opaque {}.

[thejoshwolfe]

We don't want all opaque types to be equivalent. The opaque context objects of multiple different C libraries should still cause compile errors if you pass them to the wrong library. What I mean by this is that we shouldn't rename c_void to opaque.

If we do opaque {} instead of @OpaqueType(), then it sounds like you're really proposing implicitly declaring:

const c_void = opaque{};

which I guess is cool, but it's not really clear what opaque itself is. Is it a struct that you instantiate to make a type? That's kinda weird. So it's like a type type? Can't we use @OpaqueType() instead? Then:

const c_void = @OpaqueType();

This is much easier to understand, and fits the pattern that we have with @intType(size, isSigned) where a builtin function creates a type.

[andrewrk]

I agree, upon further reflection @OpaqueType() is clearer. And it is currently true that c_void is defined as const c_void = @OpaqueType();. Also I should rename @intType to @IntType.

The opaque context objects of multiple different C libraries should still cause compile errors if you pass them to the wrong library. What I mean by this is that we shouldn't rename c_void to opaque.

I see your point. So the programmer is supposed to create a new opaque type for a new opaque thing. So whatever @AndreaOrru was doing up there for his operating system, he should make a new opaque type for that specific instance needed, which is not shared globally with all opaque things.

[andrewrk]

Still open for discussion if anyone disagrees with the above.

[andrewrk]

I'm re-opening this proposal with the argument that c_void has valid use cases outside the scope of C API compatibility. I'll put a code example here when I come across it. I can't remember at this time.

[ghost]

c_void only makes sense to access through a pointer, right? So we could save some clutter by making anyopaque equivalent to *c_void rather than c_void, much like anyframe is actually a pointer to a type-erased frame rather than the frame itself. I think this would be much more consistent with the various any types as well.

[foobles]

It seems like this would be an unnecessary addition now that opaque{} has been added. *opaque{} is fine in most contexts already. If anything, I think c_void could be removed entirely.

[ghost]

Nope -- opaque{} doesn't coerce between known-size pointers. anyopaque is a distinct concept.

[ifreund]

c_void only makes sense to access through a pointer, right? So we could save some clutter by making anyopaque equivalent to *c_void rather than c_void, much like anyframe is actually a pointer to a type-erased frame rather than the frame itself. I think this would be much more consistent with the various any types as well.

This would remove the ability to express *const c_void in the language, which I don't think is acceptable.

[nektro]

This would remove the ability to express *const c_void in the language, which I don't think is acceptable.

if this is something we want it should not be called any*

antype and anyframe do not accept any modifiers

[ifreund]

antype and anyframe do not accept any modifiers

anytype does not, as it is not actually a type but rather a keyword that may be used in place of a type expression.

anyframe (like anyopaque) is a primitive type and does accept modifiers just like any other type. For example this compiles:

export fn foo(_: *const anyframe) u32 {
    return 0;
}