It's not possible to open a file without invoking allocations for the file name

[tbu-]

File::open takes a Path object as reference, although it only clones it afterwards.

It's also impossible to re-use the allocation for the file path, because it's only dropped at the end.

[nagisa]

It is pretty hard to not involve allocations because Rust-native strings will have to be converted into null terminated one to pass into the native API at some point anyway.

[tbu-]

That's true.. Maybe we can avoid the double-allocation?

[aturon]

@tbu- The path is cloned only so that it can later be used in error messages, which is a somewhat debatable use case.

We could resolve this in the future by taking an IntoPathBuf bound (if we had a trait like that).

cc @wycats @alexcrichton

[tbu-]

@aturon In that case it would probably be better to just take a PathBuf. But does it really justify an extra allocation just to provide error messages?

[aturon]

@tbu-

In that case it would probably be better to just take a PathBuf.

That would be a lot less ergonomic -- I want to be able to feed in a string literal with no extra steps.

But does it really justify an extra allocation just to provide error messages?

Probably not, hence why I said it was a "somewhat debatable use case." :)

[alexchandel]

@nagisa What about a variable-length stack allocation?

[nagisa]

@alexchandel allocating on stack comes with its own downsides. Also, it doesn’t guarantee a trailing null byte either, AFAIK?

[tbu-]

@nagisa If you had a stack allocation, you could just append a null byte.

[alexchandel]

@nagisa As tbu- said. And the downsides of alloca are nothing compared to linking in 195kB of jemalloc (the absolute minimum jemalloc size on OS X x86_64 with LTO).