jcaesar / structstruck

Rust nested structs
MIT License
53 stars 3 forks source link

Lifetime support #2

Closed uint closed 2 years ago

uint commented 2 years ago

It would be really awesome to get support for lifetimes that sort of propagate through a whole nested structure like below.

Example usage

structstruck::strike! {
    pub enum Expr<'src> {
        Binary(struct<'src> {
             left: Box<Expr<'src>>,
             operator: BinaryOp,
             right: Box<Expr<'src>>,
        }),
        Literal(enum<'src> {
            StringLit(&'src str),
            NumLit(&'src str),
        }),
    }
}

Current error

image

Use case

I'm trying to write a Lox interpreter in Rust. structstruck would be super handy to express the AST without heaps of boilerplate :+1: I want it to be zero-copy as much as possible, hence string slices and lifetimes.

jcaesar commented 2 years ago

This is definitely on my wantlist. I was originally thinking that

structstruck::strike! {
    pub enum Expr<'src> {
        Binary(struct {
             left: Box<Expr<'src>>,
             operator: BinaryOp,
             right: Box<Expr<'src>>,
        }),
        Literal(enum {
            StringLit(&'src str),
            NumLit(&'src str),
        }),
    }
}

should work (i.e. you declare the generics/lifetimes once), but that does mean I have to check whether a parameter is used in a struct and only then add it to the declaration.
The example you posted might be a bit easier to fix, I'll have a look.

jcaesar commented 2 years ago

Ah, looks like I misunderstood the problem. This was an oversight on my part and should be fixed on master. But there's also a few other pieces missing, like the structs not being made pub automatically here. I want to take care of that before I release another version.

uint commented 2 years ago

Cool, I'll give it a try after the release!

the structs not being made pub automatically here

Ah, should this be automatic though? If the outer type is an enum, I guess it'd make sense to have nested types inherit visibility. But if the outer type is a struct, devs might want to expose the outer type while hiding the inner ones. There's probably an argument for keeping it explicit.

jcaesar commented 2 years ago

Ah, should this be automatic though?

Only in situations where you'd get a can't leak private type anyway. Which this is.

jcaesar commented 2 years ago

I decided to ignore the other issues for now. 0.2.2 published.