Thank you for providing feedback! Intertwined are my responses...

> On Apr 25, 2023, at 11:22 AM, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Tue, Apr 25, 2023 at 12:47 PM Louis Langholtz via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>>
>> The idea is to simply to add an interface to std::fstream::open that provided an fstream to "a temporary file with a unique auto-generated filename” opened with “wb+x” mode - like that produced by std::tmpfile. This would solve a seemingly otherwise vexing task of re-inventing the standard library’s existing wheels for using FILE* under the hood for std::cin, std::cout, etc without needing to expose a FILE* based interface which could still be done but orthogonally.
>
> Is `tmpfile` functionality commonly needed enough that the standard
> library needs to incorporate it into fstream?

This seems like a reasonable and significant question to be asking.

I have asked myself this too. My answer was that creating temporary files securely in C++ I/O streams, as std::tmpfile can achieve, provides critical functionality for hardening C++ and plumbing it through the standard library requires only opening existing internal support. In LLVM for example there is code like https://github.com/llvm/llvm-project/blob/main/libcxx/src/std_stream.h#L45.

As background context and in additional response to this question, I had found the following question on StackOverflow that someone else had posted in 2011 related to this proposal: https://stackoverflow.com/q/7778889/7410358. The accepted answer was to use std::tmpnam which is deprecated by LLVM and has “never use these functions” stated at https://man7.org/linux/man-pages/man3/tmpnam.3.html due to its security weaknesses.

>
>> This could be achieved simply by offering a no-parameters version of the aforementioned open member function:
>>
>> void open();
>>
>> Which to me at least, naturally suggests opening an unnamed file that was unique to the call and open for “wb+” access.
>
> What about this function's signature suggests *any* of those things?
> At least `tmpfile` says what it's doing.

This question reminds me a bit of arguments I’ve heard about whether zero was a number and what zero means. In this case, what does no arguments to the open function mean?

For me, opening an fstream with no filename means opening an unnamed file. Which is the desire. From POSIX at least, the idea that an unnamed thing should be unique seems to have precedence: take pipe and socketpair for example. And reasoning about opening an unnamed file makes no sense to me that this might be opening a file that already had any data in it. That leads it to being open for writing+.

More to your point though, I don’t find reasoning about “nothingness” necessarily trivial. I.e. I support your point that a no parameter open function may not be expressive enough. Of course using a no argument open function for this isn’t the only way to achieve this. Another way I have imagined was introducing a disambiguation tag with a more meaningful name as a sole argument (ex: “tmpfile_t”). It was actually my first consideration for this but it involves more mechanics in having to introduce a new type in addition to the new overload of open.

Lou