feat!: Implement support for generic params

[DanikVitek]

Also:

• Improve error messages
• Extendable type-safe rewrite of the macro expansion

Closes #16.

[DanikVitek]

Hello, @scouten. Ready for review

[DanikVitek]

Should be marked as "Closes #16"

[DanikVitek]

I need to add support for #[cfg_attr(..., async_generic)], so don not merge just yet

[DanikVitek]

Or rather, attributes on async_signature

[DanikVitek]

Battle-testing the implementation on borsh-rs

[scouten]

@DanikVitek this looks very interesting. I'll want to make sure the CI runs pass before merging and also for you to add the #[cfg(...)] upgrades that you are planning.

Let me know how I can help.

[scouten]

Great and welcome proposal! I look forward to the final draft as discussed in my initial comments.

[scouten]

Please remove this diff. This project uses release-plz (https://release-plz.dev/docs) to manage versioning and that infrastructure will automatically do the necessary updates at the time based on how the PR is labeled.

[scouten]

I'm also questioning whether this PR meets the criteria for bumping to a 2.0. Under the rules of semantic versioning, that should only happen if there's an incompatible API change to the library. I see changes you've made to the async_signature parameter of the macro, but do the break compatibility? If not, let's make this a 1.2.0 release (which would involve removing the ! from the PR title as I've amended it).

[DanikVitek]

as I've described in the description of the commit 6d1b01e, the changes are indeed breaking.
async_signature(a: B) means, that the async function does not have a return type, while previously this meta tag affected only the input arguments

[DanikVitek]

I might also add the sync_signature meta tag for functions to allow annotating sync functions with attributes, unique to them. For example, doc comments should be somewhat different for sync and async functions

[DanikVitek]

@DanikVitek this looks very interesting. I'll want to make sure the CI runs pass before merging and also for you to add the #[cfg(...)] upgrades that you are planning.

Let me know how I can help.

I need to add new features behind feature flags?

[scouten]

@DanikVitek no, I wasn't talking about Rust crate feature flags. What I was referring to was the Conventional Commits syntax, which is required in this project for all pull requests. I've updated the PR title to be compliant, but if this is not a breaking change, then we should remove the ! from the title.

[DanikVitek]

Now that I think about it, what are the reasons anybody would want to change the return type of their async function relative to the sync function? The only real reason I can come up with is if they're using a custom Future implementation. But in that case, why would they use this crate, as the custom future requires to move the implementation elsewhere, or surround the whole function body with an async move {...} block?

[DanikVitek]

What I was referring to was the Conventional Commits syntax

I'm sorry, then I'm not sure what you meant by me adding the #[cfg(...)] upgrades that I'm planning. Are you referring to the comment about #[cfg_attr(...)] support? If so, then I've already added, tested, and rejected the approach.
I've remade it so you just need to put the required annotations onto the async_signature, async_trait, or sync_trait. And now I'm thinking about also adding the sync_signature for this purpose.