Expected Behavior

If used inside lib.rs with #[paw::main] pub fn main(...) { ... } it should retain the pub keyword to allow calling from main.rs.

Current Behavior

error[E0603]: function `main` is private
  --> cli/src/main.rs:2:20
   |
2  |     cbor_diag_cli::main();
   |                    ^^^^ private function
   |
note: the function `main` is defined here
  --> cli/src/lib.rs:95:1
   |
95 | #[paw::main]
   | ^^^^^^^^^^^^

If we want to follow up on #1 and PR other crates to add paw support, the traits should probably be available standalone, without any of the proc macro deps.

We should probably make a paw-raw crate to hold just the traits, and re-export from the main paw crate.

Thanks for this crate. It works in one of my crates where main returns anyhow::Result<()>.
But why doesn't this work? :)

error[E0277]: the trait bound `Args: ParseArgs` is not satisfied
   --> src\main.rs:287:1
    |
287 | #[paw::main]
    | ^^^^^^^^^^^^ the trait `ParseArgs` is not implemented for `Args`
    |
    = note: required by `parse_args`

#[derive(StructOpt, Debug)]
struct Args {
	// ...
}

#[paw::main]
fn main(args: Args) -> Result<(), Box<dyn Error>> {
	// ...
}

I'm not entirely sure what we should name the trait. I just went with TryParse because it felt okay, but if it's something that stands out by itself, maybe it should be called something like ParseArgs, MainArgs, TryParseArgs?

Suggestions welcome!

Feature Request

Summary

Update syn, proc-macro2 and quote to their stable releases

Motivation

To reduce duplication in the build tree of downstream users.

I can probably submit a PR for this soon, just want to open an issue now in case I don't get round to it.

With structopt 0.2.17 paw is now supported through the 'paw' feature meaning that paw and structopt can be used just by including both in the dependencies:

[dependencies]
structopt = { version = "0.2.17", features = [ "paw" ] }
paw = "1.0"

The documentation and examples need updating and the paw-structopt crate can be deprecated.

From my reading of the code, the argument parser called by paw may panic before human-panic gets called to replace the panic hook, and if that happens the user ends up with a not-so-helpful error message.

Are there any plans for addressing this, particularly given the intention of including something like paw in std in the future?

PS. The issue template refers to a silver package.

Feature Request

Summary

clap 3.0 integrated structopts (https://github.com/clap-rs/clap#quick-example) and I wonder if it makes sense to have clap 3.0 integration in paw.

Motivation

It seems that clap is more actively maintained, so it might be better to follow it.

Guide-level explanation

It is just another option to structopt.

Reference-level explanation

The integration should be defined by an optional feature, so it will play well with the existing integrations (structopt).

Drawbacks

It is one extra integration dependency, which makes things hard to maintain.

Rationale and alternatives

We can just ignore clap 3.0 as it seems that structopt is good enough.

Unresolved Questions

Is it worth the trouble?