print buffering


(Drew Crawford) #1

We noticed today when running a swift CLI program to a pipe that stdout is fully buffered (e.g. not unbuffered, not line-buffered). So just now we committed unbuffering IO to a bunch of CLI programs.

Is this the right default behavior for Swift?

I realize this is a Cism with a long history, but I think an argument can be made that the Cism is surprising (in that: it surprised us). I think most Swift developers would assume "print" to be line-buffered.

Requiring programs to opt-in to linebuffering so they can work via pipe feels wrong to me. Am I crazy?

Drew


(Greg Parker) #2

We coincidentally got a Radar about this a few days ago.

    func testExample() {
        print("foo") // doesn't appear before the crash
        assert(false)
    }

Making print() less than fully buffered (either unconditionally or conditional on stdout being sufficiently terminal-like) ought to be reasonable. I mirrored the bug report to https://bugs.swift.org/browse/SR-1127 .

···

On Apr 1, 2016, at 2:52 PM, Drew Crawford via swift-dev <swift-dev@swift.org> wrote:

We noticed today when running a swift CLI program to a pipe that stdout is fully buffered (e.g. not unbuffered, not line-buffered). So just now we committed unbuffering IO to a bunch of CLI programs.

Is this the right default behavior for Swift?

I realize this is a Cism with a long history, but I think an argument can be made that the Cism is surprising (in that: it surprised us). I think most Swift developers would assume "print" to be line-buffered.

Requiring programs to opt-in to linebuffering so they can work via pipe feels wrong to me. Am I crazy?

--
Greg Parker gparker@apple.com Runtime Wrangler