SocketAddr associated types

[rust-embedded-community]

SocketAddr associated types

[ryan-summers]

I am very okay with a generic socketaddr type myself, as I've had these exact same issues during implementation. I don't see any specific benefit to using no-std-net, since we still have versioning issues, and there's not very convenient methods to convert between common types.

[ryan-summers]

However, how would a library that is agnostic to the underlying stack know how to construct and use these addresses? I.e. https://github.com/quartiq/minimq/blob/master/src/network_manager.rs, where we don't know what stack we're running on. Would this be the TryFrom impl bound?

[chrysn]

The versioning issues probably go away as we might use the opportunity to switch to core::net::SocketAddr as a reference type. Indeed I'd think that TryFrom<core::net::SocketAddr> and Into<core::net::SocketAddr> (Or From<Self> for SocketAddr, I always mix up which is the good one to implement) should be part of the trait bounds -- in particular, core::net::SocketAddr would stay a perfectly valid choice there.

In code such as the network managers case, there's the TcpStack: TcpClientStack generic type around, so options are (as a matter of taste, partially) to either put TcpStack::SocketAddr in the own object's signtures, or to put SocketAddr there and go through the conversions (or to go half way and put impl TryInto<TcpStack::SocketAddr> in there).

[ryan-summers]

I would love to use core::net, but it's still nightly-only behind feature(ip_in_core)

[chrysn]

Oh -- indeed, sorry, I didn't check all the way up on the documentation tree (and the types don't get the warning if their module is gated). In that case, the proposed associated types are not helping the versioning situation (but don't don't make it worse either, for where we used to use no-std-net's SocketAddr we'd now use TryFrom/Into it).