Skip to content

Proposal: Extend builtin to include compiler semver #1913

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
suirad opened this issue Feb 3, 2019 · 2 comments
Closed

Proposal: Extend builtin to include compiler semver #1913

suirad opened this issue Feb 3, 2019 · 2 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@suirad
Copy link
Contributor

suirad commented Feb 3, 2019

There should be a way to forward and backward prepare the std as well as libraries made with zig for expected changes in the language. The following are the two major examples to explain why:


STD

Currently in the std there are parts of the code that are expected to change internally once certain changes happen(i.e copy elision). At the moment, there are points of the std that are annotated with a link to github issue for it to be readdressed. There is the potential for those to be skipped over.
Since most issues are tagged with a version that it is expected to be fixed, an addition to that would be to have those points in code that need to be reworked once the newer version lands announce themselves.
It could also enable development of workarounds to problems that are expecting larger language changes to work.(i.e version locked networking without coroutines or something)

An illustrative example with psuedo-zig:

const builtin = @import("builtin");

test "Thing that needs to be reworked after coroutines" {
    // preparing for the coroutine rework to land in 0.4.0
    if (builtin.majVersion != 0 or builtin.minVersion > 3){
        @compileError("Update this test to use coroutines");
    }
    ...
}

User libraries

Currently libraries built in zig implicitly target whichever version of zig they were built for, but with this change, the code can be more portable and target specific or multiple zig versions in the same codebase.

Psuedo-zig usecase examples:

const builtin = @import("builtin");

// targeted importing
const mylibfs = switch(builtin.minVersion){
    3 => @import("mylibfs0.3.0.zig"),
    4 => @import("mylibfs0.4.0.zig"),
    else => @compileError("Unsupported Zig version"),
}

// versioned function swapping
const mylibfn = switch(builtin.minVersion){
    3 => mylibfn_without_coroutines,
    4 => mylibfn_with_coroutines,
    else => @compileError("Unsupported Zig version"),
}

fn mylibfn_without_coroutines() !void {
    // implementation without coroutines
}

fn mylibfn_with_coroutines() !void {
    // implementation with coroutines
}

test "use mylibfn" {
    // this fn can be used for both/only zig w/ minver 3 & 4
    mylibfn();
}
@andrewrk
Copy link
Member

andrewrk commented Feb 3, 2019

Related: #350 and #404

@andrewrk andrewrk added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Feb 3, 2019
@andrewrk andrewrk added this to the 0.4.0 milestone Feb 3, 2019
@andrewrk andrewrk modified the milestones: 0.4.0, 0.5.0 Feb 19, 2019
@andrewrk andrewrk modified the milestones: 0.5.0, 0.6.0 Apr 30, 2019
@andrewrk andrewrk modified the milestones: 0.6.0, 0.7.0 Oct 17, 2019
@andrewrk
Copy link
Member

#6466 is a duplicate of this however there is more activity on the other issue, so closing this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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

2 participants