<fstream>: Implement LWG-3430

[CaseyCarter]

LWG-3430 turns the constructors of basic_{i,o,}fstream that accept filesystem::path into templates that deduce the argument type and then constrain it to be filesystem::path to avoid potentially expensive implicit conversions. We already implement these constructors as templates for esoteric ABI-compatibility reasons (See

STL/stl/inc/fstream

Lines 20 to 25 in 4c862ee

	// TRANSITION, ABI: The _Path_ish functions accepting filesystem::path or experimental::filesystem::path are templates
	// which always use the same types as a workaround for user code deriving from iostreams types and
	// __declspec(dllexport)ing the derived types. Adding member functions to iostreams broke the ABI of such DLLs.
	// Deriving and __declspec(dllexport)ing standard library types is not supported, but in this particular case
	// the workaround was inexpensive. The workaround will be removed in the next ABI breaking release of the
	// Visual C++ Libraries.

) so the net change here is to make that template deduce the argument type and constrain it. I think we should also change our experimental::filesystem::path constructors in the spirit of LWG-3430, so I merged pairs of experimental / non-experimental constructors together using a new _Is_any_path trait to constrain.

Existing test coverage in tests\std\tests\VSO_0000000_path_stream_parameter seems sufficient, so I've added no new tests.

[miscco]

Thats much better

[barcharcraz]

This could break user code right? Since with our current implementation we'd accept any type with a .c_str() overload.

[CaseyCarter]

This could break user code right? Since with our current implementation we'd accept any type with a .c_str() overload.

Since the _Path_ish template parameters were only used in non-deduced contexts, and there's no way to pass explicit template arguments to a constructor, there was previously no way for a user to pass an arbitrary type with a c_str member.

This will break user code that was constructing from a type that converts to path, but that is intentional breakage per LWG-3430.

[StephanTLavavej]

Looks good - I eventually realized that the other _Path_ish occurrences for open() can't be changed like this (as tempting as it would be).

[StephanTLavavej]

Thanks for implementing this LWG issue resolution that also simplifies the code! 😺 📉 🎉