net: keep SocketConn or not?

[rsc]

See CL https://go-review.googlesource.com/#/c/9275/.
Is this really necessary? I suspect not.

[bradfitz]

I'm having a hard time understanding its docs:

SocketConn returns a copy of the network connection corresponding to the open file f and user-defined socket address sa. It is the caller's responsibility to close f when finished. Closing c does not affect f, and closing f does not affect c.

@mikioh, what does this enable users to do?

/cc @ianlancetaylor

[rsc]

I intend to write a more complete comment on the CL but I have been preempted by other work.

As I understand it, SocketConn is FileConn but allows the use of arbitrary socket address types instead of just the few that FileConn knows about. It seems to me that the net package should just keep using (and providing) only FileConn but perhaps we can put a registration mechanism in package syscall to let clients register converters between sockaddrs and net.Addr for non-standard sockaddr types.

[mikioh]

Thanks for the explanation, @rsc. Simply I wanted to allow us to mix features under the hood, various hardware-offloading stuff, new extensions for transport protocols and routing metrics for transport path selection, in existing network applications. For that purpose I needed to find out some way injecting unknown socket address and endpoint types in the standard library into runtime-integrated network poller.

perhaps we can put a registration mechanism in package syscall...

If it does make sense and is possible, I'm happy to revert the current change and will take the approach in Go 1.6.

[bradfitz]

Yes, I'd prefer it be reverted for now too and we can give it more thought for Go 1.6.

[gopherbot]

CL https://golang.org/cl/11854 mentions this issue.