ascent
ascent copied to clipboard
Remove trait bounds from generated program type's declaration
Fixes https://github.com/s-arash/ascent/issues/23
Following up on https://github.com/s-arash/ascent/issues/23#issuecomment-1858083233 I've amended this PR to support the following (optional) syntax for specifying diverging impl trait bounds:
Non-diverging impl trait bounds
If only a generic struct
is specified, then the macro will behave as is, using the provided type generics and bounds for both, the type's declaration, as well as its impls:
The following …
ascent!{
struct AscentProgram<T> where T: Clone + Eq + Hash;
// ...
}
… expands to something along the lines of this:
struct AscentProgram<T>
where
T: Clone + Hash + Eq
{
// ...
}
impl<T> AscentProgram<T>
where
T: Clone + Hash + Eq,
{
// ...
}
impl<T> Default for AscentProgram<T>
where
T: Clone + Hash + Eq
{
// ...
}
Diverging impl trait bounds
If both, a generic struct
, as well as an impl …
are specified, then the macro use the provided type generics and bounds for the type's declaration, as well as the impl Default
, while using the provided impl generics and bounds for the type's impls:
The following …
ascent!{
struct AscentProgram<T> where T: Clone;
impl<T> AscentProgram<T> where T: Clone + Eq + Hash;
// ...
}
… expands to something along the lines of this:
struct AscentProgram<T>
where
T: Clone
{
// ...
}
impl<T> AscentProgram<T>
where
T: Clone + Hash + Eq,
{
// ...
}
impl<T> Default for AscentProgram<T>
where
T: Clone
{
// ...
}
Impl-only trait bounds
Similarly the following …
ascent!{
struct AscentProgram<T>;
impl<T> AscentProgram<T> where T: Clone + Eq + Hash;
// ...
}
… expands to something along the lines of this:
struct AscentProgram<T> {
// ...
}
impl<T> AscentProgram<T>
where
T: Clone + Hash + Eq,
{
// ...
}
impl<T> Default for AscentProgram<T> {
// ...
}
Hi @regexident, and thanks again for the PR! Do you have time to fix the remaining errors in this PR? If not, let me know and I can take it from here.
I'll try to give it a go tomorrow or the day after.
@s-arash Looks like the experimental "attrs on relations" in AscentProgram
got broken my changes of the Signatures
type.
The handling of attritibute parsing within impl Parse for AscentProgram { … }
looks a bit shady to me (leaky abstraction) since any changes within Signatures
should not break the parsing of the outer AscentProgram
.
I'm not sure how to best address this. Feel free to take it from here, if you do.
The handling of attritibute parsing within impl Parse for AscentProgram { … } looks a bit shady to me (leaky abstraction) since any changes within Signatures should not break the parsing of the outer AscentProgram.
It wasn't changes to Signatures
that broke parsing, it was unnecessary changes to AscentProgram
parsing that broke AscentProgram
parsing!