You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
net.Dialer sounds like it's close to making transports pluggable the way e.g. http.Client / http.Transport behave, but reading further one realizes that net.Dialer is hardcoded to basically be net.Dial with timeouts. This makes e.g. crypto/tls DialWithDialer less useful; I can't just easily replace the whole transport layer with something that e.g. doesn't touch the host TCP stack (think unit tests, Tor, stream protocols constructed on top of UDP, and such).
Note that tls.DialWithDialer doesn't just dialer.Dial, it also accesses the Timeout field. By the time Go2 comes around, maybe /x/net/context will have grown into something that can unify this sort of behavior.
Of course, the workaround is to dial manually and use tls.Client, but then one is responsible for all the little details that are inside tls.DialWithDialer.
Naturally, I don't expect Go1 to change existing APIs, though something new might be workable. Sorry for the ramble, just felt like writing down my hopes of reusability being crushed.
The text was updated successfully, but these errors were encountered:
Dialer probably should continue to be a concrete type - the whole point is to expose control over the configuration settings in the struct. But any APIs that are written to take a Dialer only for the ability to Dial should probably take an interface that Dialer satisfies instead (or just a func).
changed the title
net: Dialer seems like it should be an interfaceJun 17, 2017
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
A language change or incompatible library change
Feedback is required from experts, contributors, and/or the community before a change can be made.
Aug 23, 2023