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

extending codegen to support instantiations of arbitrary templates #726

Open
ab9rf opened this issue Mar 1, 2024 · 1 comment
Open

extending codegen to support instantiations of arbitrary templates #726

ab9rf opened this issue Mar 1, 2024 · 1 comment

Comments

@ab9rf
Copy link
Member

ab9rf commented Mar 1, 2024

at the moment i'm looking at something akin to this:

<template-instance template-name='name'>
contents are then either
<type-parameter>
a simple type
or
a compound (which will be redued to a T_ type and used as the parameter)
or
a subordinate template-instance (for nested template instances)
</type-parameter>
or
<type-parameter type-name='...'/> which is a shorthand
this is repeated as many times as appropriate
</template-instance>

<stl-variant> would then be an alias for <template-instance template-name='std::variant'>

there's a further extension (to be done later) for dealing with function types (which is what the type parameter of std::function is) that i'm thinking will be repurposing the existing vmethod tag

we'll probably eventually want to be able to declare templates as well; there is at least one template type in g_src now -- we're ignoring that it's a template because all of the instances are binary-compatible so we can pretend they're all the same type, but this can't be counted on being the case forever, but this isn't immediately needed so that's a future thought

anyway, thoughts welcome none of this is set in stone, and i got nowhere when i tried a first pass at implementing this yesterday so i'm still at square one in this regard

Originally posted by @ab9rf in #686 (comment)

@lethosor
Copy link
Member

lethosor commented May 17, 2024

a compound (which will be redued to a T_ type and used as the parameter)

My guess is that this can be a lower priority. We can always define our own types, and defining types inline in template arguments isn't valid like it is for class fields - neither of these compile:

std::vector<struct { field a; }>
std::variant<struct { field a; }, struct { field b; }>

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

No branches or pull requests

2 participants