`<filesystem>`: LWG-3430 - `std::fstream` & co. should be constructible from `string_view`

[tiagomacarios]

After updating to Xcode 16.3 we are seeing various breaks with filesystem::path. We believe this is due to:

Xcode 16.3 release notes

LWG3430 has been implemented which disallows implicit conversion of the source arguments to std::filesystem::path when constructing std::basic_*fstream. This effectively removes the possibility to directly construct a std::basic_*fstream from a std::basic_string_view, a input-iterator or a C-string, instead you can construct a temporary std::basic_string. This change has been applied to C++17 and later.

LWG3430 - std::fstream & co. should be constructible from string_view

It looks like the MSVC STL is the only STL that does not implement this change which causes a fair bit of headache for large codebase that need cross-platform compatibility. Would it be possible to implement it?

[cpplearner]

It seems to me that MSVC does implement LWG-3430, and what you observed is a MSVC extension.

STL/stl/inc/fstream

Lines 53 to 55 in d43d49a

	explicit basic_ifstream(
	const wstring& _Str, ios_base::openmode _Mode = ios_base::in, int _Prot = ios_base::_Default_open_prot)
	: basic_ifstream(_Str.c_str(), _Mode, _Prot) {} // extension

I think it makes sense to remove this non-Standard extension and force users to use ws.c_str() instead, but note that this won't improve cross-platform compatibility: Windows and Unix-like systems use different character types to represent pathnames, which affects filesystem::path::value_type and thus affects the availability of this Standard constructor:

explicit basic_fstream(
  const filesystem::path::value_type* s,
  ios_base::openmode mode = ios_base::in | ios_base::out);  // wide systems only; see [fstream.syn]

[StephanTLavavej]

Thanks for reporting this. We talked about it at the weekly maintainer meeting and mostly agree with S. B. Tam (@cpplearner) - we have implemented LWG-3430 (in #1968), and the remaining implementation divergence is due to the non-Standard constructor extension of taking const wstring&.

We generally avoid adding non-Standard extensions these days. However, because Windows uses wchar_t as its native path character type, we feel that the const wstring& extension is reasonable on Windows, and if anything, the much later addition of the Standard constructor from const filesystem::path::value_type* (i.e. const wchar_t* on Windows) makes us even more comfortable with the extension. Removing it would break a bunch of existing user code on Windows that's constructing fstreams from wstrings, and for no clear portability benefit, as Unix and Windows simply fundamentally differ on their path character type.