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

Should structs use existing module generative code system? #2

Open
VonTum opened this issue Aug 10, 2024 · 0 comments
Open

Should structs use existing module generative code system? #2

VonTum opened this issue Aug 10, 2024 · 0 comments
Labels
Request Input These are issues about the design of the language, and thus should be discussed

Comments

@VonTum
Copy link
Collaborator

VonTum commented Aug 10, 2024

So I've been looking to add structs to SUS. But I'm not entirely convinced by my current approach.

Basically, I had the idea of integrating struct declarations with the existing SUS generative code system, but instead of

A regular struct looks pretty unassuming:

struct MyVec3 {
    int x
    int y
    int z
}

And having the generative code would allow for templated structs like

struct MyVec<T> {
    input gen int SIZE
    
    T[SIZE] arr
}

And even structs with optional fields like

struct BRAMRead<T> {
    input gen bool ECC_INCLUDED
    
    T read_data
    if ECC_INCLUDED { // (compiletime)
        bool ecc_did_error
    }
}

The idea here is that any non-gen (compiletime) declaration is interpreted as a struct field, whereas gen declarations (like the template parameters), are executable compile-time code.

While this is easy to implement, and even gains a little bonus for language consistency, I can't help but fear I might be shooting myself in the foot somehow.

@VonTum VonTum added the Request Input These are issues about the design of the language, and thus should be discussed label Aug 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Request Input These are issues about the design of the language, and thus should be discussed
Projects
None yet
Development

No branches or pull requests

1 participant