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

Add record! macro for making labelled HLlists #126

Open
lloydmeta opened this issue Sep 25, 2018 · 3 comments
Open

Add record! macro for making labelled HLlists #126

lloydmeta opened this issue Sep 25, 2018 · 3 comments

Comments

@lloydmeta
Copy link
Owner

https://github.com/lloydmeta/frunk/pull/124/files/7e4bc32eeac38288f9cedf60c5e5ab68c54e3f30#r220041930

Proposal

I wonder if we should add a macro:

record! { // bikeshed
    name: "joe",
    age: 3,
    is_admin: true,
}

Possibly also:

Record! { // bikeshed
    name: &'static str,
    age: i32,
    is_admin: bool,
}
@ExpHP
Copy link
Collaborator

ExpHP commented Sep 25, 2018

This looks like the perfect use case for function procedural macros, which IIRC are being stabilized in this release cycle?

@ExpHP
Copy link
Collaborator

ExpHP commented Oct 3, 2018

I may have misinterpreted; I thought the identifiers were interpreted as the field names, but I now see it's possible that they were already assumed to exist as type aliases.

In the latter case, this macro is already possible with macro_rules; but a label! proc macro to generate the field label types would still be cool.

Having Record! support both type field = (f, i, e, l, d); and automatic label type generation can be done using string literals to disambiguate:

Record! {
    age: u32, // uses the existing type `age`
}

Record! {
    "age": u32, // generates a label type
}

(But more is not always better)

@Centril
Copy link
Collaborator

Centril commented Oct 3, 2018

The automatic generation of the label type does seem like a win in terms of ergonomics and let's you get away with being more ad-hoc "on the flow".

Perhaps for disambiguation, a leading sigil would be clearer, e.g.:

Record! {
    !age: u32, // generates a label type
}

Bikeshed on the sigil of course, for example: ~age, .age, +age, #age

On the other hand, a benefit of macro_rules is that it can be in the same crate...
But perhaps we want to make poly_fn a proc macro too?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants