5 ms·
The order of os.Stdout, os.Stdin is interesting. I'd assume src->dest being more intuitive order. Any ideas if this dest<-src order is by design following go d
by AhtiK 13y ago
The order of os.Stdout, os.Stdin is interesting.
I'd assume src->dest being more intuitive order.
Any ideas if this dest<-src order is by design following go design principles or was mainly authors' personal choice?
By the way, Pipe in the same package is the other way around: (PipeReader, PipeWriter)
- arthurbrown 13y agoChannels in go use the exact syntax you mention (dst <- src). With this in mind, the argument order of io.Copy is consistent, as well as io.Pipe. You read from a reader - the output of the pipe, and write to a writer - the input of the pipe.
- jzwinck 13y agomemcpy() and strcpy() and a whole bunch of functions inspired by them have take (dest, source). Maybe it's not theoretically superior, but it is familiar to a whole lot of programmers.
- tcard 13y agoIt is by design. All those work in the same direction: dest = src // Variable assignment. <-ch; // Read from channel. // in net/http type HandlerFunc func(w ResponseWriter, req *Request) // in io func Copy(dst Writer, src Reader) // builtin copy(dst, src) // Slices. So the reason is consistency. I suppose the Pipe exception is to map Unix's pipes.