Const pointer semantics

Brainstorming
1

Consider the following function that I want to be able to use for both *const Foo and *Foo arguments:

fn getBar(foo: *const Foo) *Bar {
    //return foo.bar;  //errors out
    return @constCast(foo.bar);
}

I’m here to argue that the language semantics should be changed so that the @constCast here is not needed, and instead any potential const mismatch be identified at the call sites instead:

const foo_v: *Foo = ...;
const foo_c: *const Foo = ...;

const bar_vv: *Bar = getBar(foo_v); //pass
const bar_vc: *Bar = getBar(foo_c); //fail
const bar_cc: *const Bar = getBar(foo_c); //pass
const bar_cv: *const Bar = getBar(foo_v); //pass

This would allow the same function to be used for both const and non-const pointers without compromising const-safety.

const in this case is a little bit unintuitive, because it essentially widens the set of possible input of a function, while it does the opposite to the output.

2

Do you have any real usecases where this would help? In my experience I take a *T if I change anything in T (thus requiring a mutable pointer) and a *const T otherwise (allowing both cases), which hasnt let me down yet.

In this vein I do see some use for propagating sentinels, which Ive ran into using std.mem.cut* with a [:0]const u8.

In general this is already possible with fn (v: anytype) @TypeOf(v) { ... }, but its clunky

3

As for the use case I made the post in the first place because I encountered this in my code:

    fn getEntity(g: *const Game, id: EntityID) *Entity {
        return @constCast(&g.entities[@intFromEnum(id)]);
    }

I’m using this function both in the game logic which takes *Game (and assigns it to *Entity), and in the renderer which takes *const Game (and must assign it to *const Entity).

4

The solution for this Ive seen used here and there is to have fn get() as well as fn getConst() which is mostly fine if the code is a trivial typesafe getter like this imo. Not a fan of the duplication but there isnt a good fix.

To go deeper into your proposal, this would bring the type forwarding system (I think its called RLS) to funtion return types. The immediate problem I see is how you keep sane function signatures, something like fn fooGetter(*maybeconst Foo) *maybeconst Bar but then you just have anytype wrapped in a fairly niche blanket. There might be existing issues (id guess on github), you might find something more substantial there than what Im saying here.

1 Like
5

I think that what you’re asking here is tantamount to having the language implicitly infer return type. We can certainly argue about whether this is a good idea, but what you’re describing is already possible in zig just by being explicit about the return type.

const Bar = u8;
const Foo = struct{bar : Bar};

fn getBar(foo : anytype) constp(@TypeOf(foo), Bar) {
    // Add asserts here to ensure foo is *Foo or *const Foo
    return &foo.bar;
}

fn constp(T : type, U : type) type {
    if(@typeInfo(T).pointer.is_const) {
        return *const U;
    } else {
        return *U;
    }
}

test "getBar test" {
    var foo_v = Foo{.bar = 0};
    const foo_c = Foo{.bar = 1};

    const bar_vv : *Bar = getBar(&foo_v); _ = bar_vv; // pass
    const bar_cv : *Bar = getBar(&foo_c); _ = bar_cv; // fail
    const bar_vc : *const Bar = getBar(&foo_v); _ = bar_vc; // pass
    const bar_cc : *const Bar = getBar(&foo_c); _ = bar_cc; // pass
}

It looks like there’s an old github issue discussing return type inference which was eventually discarded.

1 Like
6

Is the code-gen smart enough to deduplicate those functions (in case they don’t get inlined)?

7
8

std.BoundedArray used to work like this:

Zig Documentation

It has been removed from std, but the structure and the pattern are still useful

9

Doesn’t look like it.

10

Btw, this is essentially the same problem that C used to have with functions like char *strchr( const char *str, int ch) which silently removed the const of the passed string when it was returned.

C solved this in C23 with type-generic macro wrappers, see N3020.

I guess the Zig equivalent to this are @typeInfo switches like @Naois suggested. The biggest annoyance with these comptime-generated return types in practice is that ZLS usually doesn’t understand them, and you lose code completion support in the IDE for the result (have not tested it for this case).

11

Hear me out:

fn slice(x: *|ptr_attr|BoundedArray) []ptr_attr T {
    return x.buffer[0..x.len];
}
1 Like