Skip to content
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

comptime should not be allowed in type expressions: e.g. var foo: comptime u64 #3976

Closed
momumi opened this issue Dec 23, 2019 · 1 comment
Closed
Labels
accepted This proposal is planned. breaking Implementing this issue could cause existing code to no longer compile or have different behavior. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@momumi
Copy link
Contributor

momumi commented Dec 23, 2019

A comptime variable in zig uses the syntax comptime var foo: u64, however the compiler also accepts var foo: comptime u64. The compiler seems treat the latter case as equivalent to var foo: u64, but I think it should be a syntax error.

For example this program will compile and run without errors:

const std = @import("std");

pub fn main() void {
    var x: comptime u64 = std.time.milliTimestamp();

    std.debug.warn("time: {}\n", .{x});
}

On a slightly related note, the zig grammar in the docs seems to be very wrong/outdated (e.g. a CHAR_LITERAL would be a valid TypeExpr), but that's probably a separate issue.

@andrewrk andrewrk added proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. breaking Implementing this issue could cause existing code to no longer compile or have different behavior. labels Dec 31, 2019
@andrewrk andrewrk added this to the 0.7.0 milestone Dec 31, 2019
@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 27, 2020
@SpexGuy SpexGuy added the accepted This proposal is planned. label May 6, 2021
@SpexGuy
Copy link
Contributor

SpexGuy commented May 6, 2021

This was recently added as part of #8364. Closing this in the interest of having only one issue to track the change.

@SpexGuy SpexGuy closed this as completed May 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted This proposal is planned. breaking Implementing this issue could cause existing code to no longer compile or have different behavior. proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Projects
None yet
Development

No branches or pull requests

3 participants