Go: net: meta bug for Go2 changes

[bradfitz]

This is a meta/index bug for things we might change in a possible future net/v2 (~ "Go 2") package, including both links to other issues, or just comments with API problems/cleanups that are too little to warrant their own bugs.

(This is not about net/http, net/mail, net/rpc, net/smtp, net/nextproto, or net/url. Those should have their own bugs if/when needed.)

[bradfitz]

There's probably at least 1 too many ways to read from a UDP Conn:

go1.txt:pkg net, method (*UDPConn) Read([]uint8) (int, error)
go1.txt:pkg net, method (*UDPConn) ReadFrom([]uint8) (int, Addr, error)
go1.txt:pkg net, method (*UDPConn) ReadFromUDP([]uint8) (int, *UDPAddr, error)
go1.1.txt:pkg net, method (*UDPConn) ReadMsgUDP([]uint8, []uint8) (int, int, int, *UDPAddr, error)

Likewise with UnixConn and IPConn.

And maybe they're still not sufficient because it says at:

https://golang.org/pkg/net/#UDPConn.ReadMsgUDP

The packages golang.org/x/net/ipv4 and golang.org/x/net/ipv6 can be used to manipulate IP-level socket options in oob.

Maybe we can get it right in one place and remove some of the redundant ones.

[bradfitz]

• #15735 - net: add mechanism to wait for readability on a TCPConn
• #18757 - net: change ParseIP to return (IP, error)

[cespare]

Also the more general

• #18804 - net: reconsider representation of IP

[networkimprov]

This is now tagged for 1.13, but has been open since 2012

• #4373 - net: errClosing not exported

[mikioh]

A few things in my mind, though each of these must be an individual proposal and I still have no concrete draft-proposals yet:

1. A buffering mechanism between packages close to users and packages close to protocol stacks, for example, the packages net/http, crypto/tls and net. The motivation behind this is, a) to achieve efficient layered buffering interacting with transport-layer protocol properties, as in, link/path MTUs and capsulation overhead, b) to provide a way to handle both partial reads/writes on connection-oriented protocols and message reads/writes on connection-less protocols seamlessly, to help applications using io.Reader interface over datagram/message-based protocols.

2. A printer for network-specific types, for example, net.IP and net.HardwareAddr. The motivation behind this is to provide a way to control various output forms of the types for people who need to work on systems using pipelines of various text forms.