Comment by Gwen Mittertreiner (JIRA)

@millenomi Would this be a reasonable thing to add to Foundation?

FileHandle already provides handles to write to the null device (via its .nullDevice property).

What is your intended use? Note that in the general case we cannot add API surface to swift-corelibs-foundation that doesn’t already exist on Darwin.

Comment by Gwen Mittertreiner (JIRA)

This came up with the contentEqual tests in the form of having to write:

#if os(Windows)
        XCTAssertTrue(fm.contentsEqual(atPath: "NUL", andPath: "NUL"))
#else
        XCTAssertTrue(fm.contentsEqual(atPath: "/dev/null", andPath: "/dev/null"))
#endif

Where it would significantly more portable to expose something like fm.contentsEqual(atPath: fm.nullDevice.path, andPath: fm.nullDevice.path)). However, I could see it used with any sort of api which accepts a string path or url to a file to read or write from. For example, where to log output to or where to read a config file from.

What do you mean by something already existing on Darwin? As it it already exists in the objective-c Foundation?

Correct. It is not a goal of the project to introduce new API, because it is meant to allow source portability, and code that isn't compilable on Darwin is by definition not portable.

If this is a need in the tests, perhaps the tests should have that as a utility. I don't recall the need being widespread within TestFoundation, though.

Comment by Gwen Mittertreiner (JIRA)

Alright, I'll keep this as a one off for the test(s) that need it.