[poincaredisk]

"completely solves" is a bit of an overstatement. Imagine a curl-like library that allows you to make requests by URL. You may only ever use HTTP urls, but code for all the other schemas (like HTTPS, FTP, Gopher) needs to be compiled in as well.

This is an extreme example, but the same thing happens very often at a smaller scale. Optional functionality can't always be removed statically.

[vvanders]

That only applies when dynamic dispatch is involved and the linker can't trace the calls. For direct calls and generics(which idiomatic Rust code tends to prefer over dyn traits) LTO will prune extensively.

[rafram]

    let uri = get_uri_from_stdin();
    networking_library::make_request(uri);

How is the compiler supposed to prune that?

[f_devd]

  let uri: Uri<HTTP> = get_uri_from_stdin().parse()?; 

If the library is made in a modular way this is how it would typically be done. The `HTTP` may be inferred by calls further along in the function.

[whstl]

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

[f_devd]

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.

[tmtvl]

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;

[okanat]

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.

[saagarjha]

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

[devnullbrain]

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

[nicoburns]

I guess that depends on the implementation. If you're calling through an API that dynamically selects the protocol than I guess it wouldn't be removable.

Rust does have a feature flagging system for this kind of optional functionality though. It's not perfect, but it would work very well for something like curl protocol backends though.

[api]

That's a consequence of crufty complicated protocols and standards that require a ton of support for different transports and backward compatibility. It's hard to avoid if you want to interoperate with the whole world.