fix parameter confusion in macros #302
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
macros resolve scope parameters and regular parameters through the
ToAnyParams
trait, losing the ability to discriminate between the two in a static way. This leads to panics instead of compilation errors.Note: this PR fixes the issue of mistakenly providing a term-like value (most likely a string) where a public key is expected. It also removes the provided
impl ToAnyParam for PublicKey
. Since this implementation never makes sense with the other changes, it’s fine to remove it as a bugfix.The code still uses
ToAnyParam
for datalog terms, which allows to provide a public key value when implementing it.Completely removing this possibility requires removing the
ToAnyParam
conversion trait altogether, which requires careful thought. This is what #314 is about.That being said, this PR already removes the possibility of honest mistakes when using macros, so it’s valuable in itself.
Fixes #301
ToDo
Item
ToAnyParam
for datalog termsPublicKey
directly for scope paramsimpl ToAnyParam for PublicKey
try usingInto<Term>
instead ofT: ToAnyParam
try usingInto<(PublicKey, Vec<PublicKey>)>
instead ofPublicKey