Rust main Has a Fixed Entry Signature and Reads Inputs from the Environment

The operating system does not call a Rust binary by constructing arbitrary Rust values for its parameters. The language entry point has a defined signature, so adding port: u16 to main produces E0580.

The failing fixture treats main like an ordinary dependency-injected function.

The runtime owns the first call

Rust startup code invokes main according to the language and target runtime contract. Command-line arguments arrive through process facilities, not as typed Rust parameters selected from the source signature.

The official E0580 page states that main should not take arguments. The Reference defines accepted main function forms and termination behaviour.

Parse untrusted process input explicitly

The repaired fixture keeps fn main() and reads the first command-line value through std::env::args. It parses a u16 and falls back to 8080.

For production, silently falling back after an invalid supplied value may be undesirable. I distinguish “argument absent” from “argument present but malformed” and return a useful error for the latter.

Operating-system strings are untrusted input. Parsing is a validation boundary, not boilerplate to hide.

Keep application logic in an ordinary function

I often structure a binary as:

fn run(config: Config) -> Result<(), Error> { /* ... */ }

fn main() -> ExitCode {
    // parse, call run, report
}

run can accept typed dependencies and is easy to test. main remains a small adapter between the process environment and the application.

This preserves the dependency-injection goal that motivated the invalid parameter without changing the special entry signature.

Main may return a termination type

Rust permits return types implementing Termination, commonly Result in suitable forms or ExitCode. This controls how completion becomes a process status.

It does not permit arbitrary inputs. Input and output sides of the entry boundary follow different rules.

I avoid calling process::exit deep in application logic because it skips normal stack unwinding and makes testing harder. Returning errors to main preserves cleanup opportunities.

Non-Unicode arguments need args_os

std::env::args expects valid Unicode and can panic when an argument is not Unicode. Paths and arbitrary operating-system values may require args_os and OsString handling.

A port number is ASCII and can be parsed from Unicode text reasonably. File paths should usually remain OS strings until an API specifically requires text.

Async runtimes transform main through macros

Attributes such as #[tokio::main] generate a synchronous entry point that builds a runtime and executes an async function. The source may look like async fn main(), but the macro owns the transformation.

Macro-specific allowed signatures and feature requirements remain separate from Rust's raw entry rule. I inspect expansion when diagnostics refer to generated startup code.

Libraries should not read process configuration deep inside helpers

Although main can call env::args, I keep that process-specific access near the binary boundary. A library function that reads global arguments is hard to reuse in tests, embedded programs, or another binary in the workspace. Parsing into Config once also gives precedence rules—flags, environment, and files—one documented owner. I validate values before starting threads or opening sockets, so configuration failures produce a clean message without partial application startup.

Panics and exit codes are part of the user interface

Using unwrap in a tutorial keeps the parser short, but a real command should report which argument was invalid and return a non-zero status. I avoid printing the same error at several layers. The parser creates a structured error, run propagates it, and main chooses final human formatting and exit code. This arrangement keeps domain functions independent from terminal output and makes failure cases easy to exercise in unit tests.

My E0580 checklist

• Is this function the special binary entry point?
• Did I add an ordinary typed input parameter?
• Where does the raw value actually arrive: arguments, environment, stdin, or config?
• Is absence different from invalid input?
• Can parsing feed a testable run(Config) function?
• Should main return Result or ExitCode?
• Do path-like arguments require args_os?
• Is an async runtime macro transforming the signature?

The core principle is that main adapts an external process boundary into typed application code. I keep its entry signature valid and move dependency-rich logic into ordinary functions.