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

Proposal: Allow var to appear recursively in ParamDecl #3642

Open
brodeuralexis opened this issue Nov 10, 2019 · 0 comments
Open

Proposal: Allow var to appear recursively in ParamDecl #3642

brodeuralexis opened this issue Nov 10, 2019 · 0 comments
Labels
proposal This issue suggests modifications. If it also has the "accepted" label then it is planned.
Milestone

Comments

@brodeuralexis
Copy link
Contributor

brodeuralexis commented Nov 10, 2019

Abstract

Allow var to appear inside generic arguments in the context of ParamDecl.

Problem

Considering the following generic:

fn Matrix(comptime N_: usize, comptime M_: usize, comptime T_: type) type {
    return struct {
        pub const N = N_;
        pub const M = M_;
        pub const T = T_;
        data: [N][M]T,
    };
}

When instantiating generics, an anonymous struct is created and cached for subsequent call to the generic with the same arguments.

While it is possible to get a type from a generic and some arguments (generic + arguments = type), it is not possible to get back the arguments from a generic and a concrete type (type - generic = arguments).

In order to have access the arguments of a generic, the values must be passed explicitly as other arguments to the function:

fn add(comptime N: usize, comptime M: usize, comptime T: type, matrix: Matrix(M, N, T), scalar: T) Matrix(N, M, T) 

Proposal

This proposal is to refine the use of anytype in the context of ParamDecl by allowing it to appear in arguments of generics like so:

fn add(matrix: Matrix(anytype, anytype, anytype), scalar: @typeOf(matrix).T) Matrix(@typeOf(matrix).N, @typeO(matrix).M, @typeOf(matrix).T)

Adding this feature to the language may also help prevent errors when using generic APIs like std.fmt, while being more helpful for language tools.

pub const Foo = struct {
    // ...

    pub fn format(value: Foo, comptime fmt: []const u8, options: std.fmt.FormatOptions, writer: std.io.Writer(anytype, anytype, anytype)) @typeOf(writer).Error!void  {
        // ...
    }
}

There is no need to add additional syntax or keywords to facilitate the extraction of the generic arguments' values, as simply exposing them as const values on the returned struct itself will allow one to get back the values with @typeOf(...).Arg.

Discussion

I believe this would required a change to the grammar to allow KEYWORD_anytype inside TypeExpr and do a validation pass on TypeExpr inside ParamDecl that are using KEYWORD_anytype.

If such a proposal is accepted, would it make sense to allow KEYWORD_anytype to also appear in all TypeExpr like variable declarations and return types, assuming that each anytype resolves to a single concrete sized type at compile time ?

// `anytype` resolves to f32.
var matrix: Matrix(3, 3, anytype) = Matrix(3, 3, f32).init();

pub fn MatrixBuilder(comptime N: usize, comptime M: usize) type {
    return struct {
        // `anytype` resolves to bool.
        pub fn ofBools() Matrix(N, M, anytype) {
            return Matrix(N, M, bool).init();
        } 
    };
}
@brodeuralexis brodeuralexis changed the title Proposal: Allow var to appear recursively in param_decl Proposal: Allow var to appear recursively in *ParamDecl* Nov 10, 2019
@brodeuralexis brodeuralexis changed the title Proposal: Allow var to appear recursively in *ParamDecl* Proposal: Allow var to appear recursively in ParamDecl Nov 10, 2019
@daurnimator daurnimator added the proposal This issue suggests modifications. If it also has the "accepted" label then it is planned. label Nov 10, 2019
@andrewrk andrewrk added this to the 0.7.0 milestone Nov 14, 2019
@andrewrk andrewrk modified the milestones: 0.7.0, 0.8.0 Oct 27, 2020
@andrewrk andrewrk modified the milestones: 0.8.0, 0.9.0 May 19, 2021
@andrewrk andrewrk modified the milestones: 0.9.0, 0.10.0 Nov 23, 2021
@andrewrk andrewrk modified the milestones: 0.10.0, 0.11.0 Apr 16, 2022
@andrewrk andrewrk modified the milestones: 0.11.0, 0.12.0 Apr 9, 2023
@andrewrk andrewrk modified the milestones: 0.13.0, 0.12.0 Jul 9, 2023
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

3 participants