> I would prefer a str be a str be a str, regardless of how you got it. Lowercase type-name and fundamental like an integer. The lowercase type names are reser

> I would prefer a str be a str be a str, regardless of how you got it. Lowercase type-name and fundamental like an integer. The lowercase type names are reserved to primitives. The String type is not a primitive but a comprehensive data structure, hence the capital S. The String type contains an `str` primitive though, along with size information. > I don't want to become a string expert to build a filename, and the default implementation could (at least conceptually) be always on the heap for all I care. Is it that hard to understand that when you create a string, you will create it as either a `String` or `PathBuf`? File methods are designed to automatically convert input parameters into a `&Path` so it doesn't matter what string structure you provide. There is also no way (currently) to create a stack-allocated string with the standard library out of the box. You can do this with crates like `arrayvec` though. It's very much opt-in for that performance. let path = String::from("/tmp/file"); let mut file = File::open(&path).unwrap(); > Looking at the present and the future, why is that a sensible default? Both x64 and ARM are going to use a 64 bit integer register for the operations, and many of those operations are going to be 1-clock throughput. You can probably find a counter example, but 32 bit integers aren't generally faster than 64 bit ones. No need to use a 64-bit integer when you only need a 32-bit integer. You can fit two 32-bit integers into a single 64-bit integer and perform a calculation on both simultaneously with a single cycle, versus spending two cycles to calculate two 64-bit integers. There's also no need to pay that memory cost either.