Skip to content

Comptime Struct Field Assignment #6656

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
nsmryan opened this issue Oct 11, 2020 · 2 comments
Closed

Comptime Struct Field Assignment #6656

nsmryan opened this issue Oct 11, 2020 · 2 comments
Labels
bug Observed behavior contradicts documented or intended behavior miscompilation The compiler reports success but produces semantically incorrect code. stage1 The process of building from source via WebAssembly and the C backend.
Milestone

Comments

@nsmryan
Copy link

nsmryan commented Oct 11, 2020

I ran into a strange situation with struct fields that are declared comptime. It appears that they must be assigned an initial value in their declaration (which makes sense), but then assigning them explicitly does not change this value.

The code below is accepted and runs, but the value set in the initialization of the struct (in the init function) is not used. This causes the final testing.expect to fail because the value of 'id' is still true.

const std = @import("std");
const testing = std.testing;

const State = struct {
    comptime id: bool = true,

    pub fn init(comptime id: bool) State {
        return State{ .id = id };
    }
};

test "test states" {
    var s1 = State.init(true);
    testing.expect(s1.id == true);

    var s2 = State.init(false);
    testing.expect(s2.id == false);
}

This may be the expect behavior for comptime fields, but it seems that the 'init' function shouldn't compile in this case.

The purpose of this code was an attempt to perform compile-time checking of state transitions. Type parameters work, but only allow a single output state (perhaps a minor limitation). Without the ability to be generic over the output type (as far as I can tell) the only way I could think to write a function that might return different states was comptime assertions on a comptime field which held the current state.

@DutchGhost
Copy link

DutchGhost commented Oct 12, 2020

This idea is covered by #5895 !

@andrewrk andrewrk added bug Observed behavior contradicts documented or intended behavior stage1 The process of building from source via WebAssembly and the C backend. labels Oct 13, 2020
@andrewrk andrewrk added this to the 0.8.0 milestone Oct 13, 2020
@andrewrk
Copy link
Member

Expected behavior is a compile error when you try to set id = false.

@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 Nov 6, 2020
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 May 19, 2021
@SpexGuy SpexGuy added the miscompilation The compiler reports success but produces semantically incorrect code. label Jul 2, 2021
wooster0 added a commit to wooster0/zig that referenced this issue Dec 7, 2022
wooster0 added a commit to wooster0/zig that referenced this issue Dec 7, 2022
wooster0 added a commit to wooster0/zig that referenced this issue Dec 8, 2022
wooster0 added a commit to wooster0/zig that referenced this issue Dec 9, 2022
@andrewrk andrewrk modified the milestones: 0.12.0, 0.11.0 Dec 10, 2022
kcbanner pushed a commit to kcbanner/zig that referenced this issue Dec 10, 2022
TUSF pushed a commit to TUSF/zig that referenced this issue May 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Observed behavior contradicts documented or intended behavior miscompilation The compiler reports success but produces semantically incorrect code. stage1 The process of building from source via WebAssembly and the C backend.
Projects
None yet
Development

No branches or pull requests

4 participants