No, this wouldn't work. The type of the request needs to be dynamic because the user can pass in any URI.

Then they can also pass in an erroneous URI. You still need some way to deal with the ones you're not accepting.

So what happens if the user passes an url containing ftp:// or even https:// to stdin? Or is this an HTTP only library?

Depends on what is desired, in this case it would fail (through the `?`), and report it's not a valid HTTP Uri. This would be for a generic parsing library that allows for multiple schemes to be parsed each with their own parsing rules.

If you want to mix schemes you would need to be able to handle all schemes; you can either go through all variations (through the same generics) you want to test or just just accept that you need a full URI parser and lose the generic.

If you want to mix schemes you should just mix schemes.

  let uri: Uri<FTP or HTTP or HTTPS> = parse_uri(get_uri_from_stdin()) or fail;

See, the trait system in Rust actually forced you to discover your requirements at a very core level. It is not a bug, but a feature. If you need HTTPS, then you need to include the code to do HTTPS of course. Then LTO shouldn't remove it.

If your library cannot parse FTP, either you enable that feature, add that feature, or use a different library.