so we can use defmt for these types

There should be something like a no_std TCP echo server example.

I am getting the following error when trying to compile my project using no-std-net:

   Compiling no-std-net v0.2.2
error[E0554]: #![feature] may not be used on the stable release channel
  --> /home/vgolub/.cargo/registry/src/github.com-1ecc6299db9ec823/no-std-net-0.2.2/src/lib.rs:43:1
   |
43 | #![feature(slice_patterns)]
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^

Hi, do you have any plan to implement std::net::AddrParseError in no_std_net ?

AddrParseError | An error which can be returned when parsing an IP address or a socket address.

I'd like to see analogs to the IPv4 and IPv4 enums/structs for MAC addresses, including a SocketAddr enum variant. Would a PR for that kind of change be welcome?

The core::net module is heading for stabilization. It's currently stable in beta and will be stable in the next stable Rust release (1.77) unless it's reverted for some reason. That's good news, because it means custom crates like this one won't be needed any longer to get basic network primitives in no_std.

I'm not sure if there is any concrete action for this crate to take once the stabilization happens. Dynamic rustc version detection to determine if the crate should just act as a facade or not can be a bit iffy, and also does not come without a bunch of dependencies just for said detection.

There can probably be a readme update advising people to use core::net instead, if their MSRV allows it.

hey, would you be interested in feature-gating this to act as a facade so std would expose the standard library types and not(std) would expose the local crate types? this would make it easier to write libraries that are agnostic over std/no_std, but still work with third party networking components in the std case.

this would be useful prior to rust-lang/rfcs#2832 landing and being implemented, and for types not included in this RFC (SocketAddr etc.)

nominally it would be good to test to ensure each variant provides the same interfaces as part of this (and any variation in interfaces would ideally be resolved, which may be a braking change), but practically introducing the feature-gate without anything else would still help a bunch.

v0.6.0 doesn't build either