RFC: Add std::net::MacAddr48 to std::net #2082
Conversation
scottmcm
added
the
T-libs-api
0000-net-mac-address.md
Outdated
| # Detailed design | ||
| [design]: #detailed-design | ||
|
|
||
| It is proposed that the existing `crate` `eui48` be used (http://crate.io/eui48) as a basis for this RFC, thus the code below is copied directly from that implementation. |
There was a problem hiding this comment.
There was a problem hiding this comment.
Fixed, thanks for pointing it out.
|
The alternative of
Also, there exist both EUI-48 and EUI-64 addresses; does it make sense to have a type for one and not the other? |
|
|
||
| Currently there is no standard way to communicate physical (or ethernet) addresses when doing network related development in rust, even though `std::net::IpAddrV4` and `std::net::IpAddrV6` exist. The MAC address is, however, a regularly occurring data-structure when doing any type of network related development. | ||
|
|
||
| There is also a proliferation of implementations which are not compatible with each other, forcing developers to manually implement the data type again and again, reducing the opportunity for code re-use and convenience. `nom`[1], `libpnet`[2] and `diesel`[3] being a couple of examples. |
There was a problem hiding this comment.
This exact argument applies equally to dozens if not hundreds of types. If I took this this RFC and find/replaced MacAddr48 with Uuid or Path or Polygon or Rgb or Rgba or Netmask or Quaternion or Matrix or Vector or TraceId and what would change? Libstd should not be the dumping ground for every possible type that could exist.
The IpAddr types are defined in the standard library because they're used in networking APIs. MacAddr48 on the other hand would be an orphaned type which interacts with nothing.
There was a problem hiding this comment.
The best (IMO) language design solution here is to support some subset of "cubical type-checking" (an implementation of Homotopy Type Theory), and allow users of multiple libraries to specify equivalences (bidirectional conversion functions, more or less) between the libraries' definitions of the same type, to allow them to be used interchangeably.
Although that might as well be a pipe dream, or there'd need to be some compromise and the compiler wouldn't check conversion preserves information, but trust the user instead.
There was a problem hiding this comment.
@sfackler fair enough, is this a criteria for all types in the std lib? Perhaps there is an argument for the inclusion of that list of types you mentioned? As said in the RFC, I don't believe in exploding the std lib and creating a massive maintenance burden (although a bunch of those are kind of settled and should not need much maintenance/tweaking going forward), but I can also see an argument for more types in the std lib as a part of the whole rust usability drive this year.
To me, extended, standardized, type support could be seen as an enabler for:
Standardized, solid, types helps with integration into other languages (rust-lang/rust-roadmap-2017#14), definitely helps with writing robust (and scalable) servers (
rust-lang/rust-roadmap-2017#9) and pushes the quality of crates up through interoperability (rust-lang/rust-roadmap-2017#10).
There is no real reason to believe that each crate using the types you mentioned (and MacAddr48) would go to the trouble of implementing all the idiomatic conversion functions and Traits that can be expected/found in the current std lib.
I understand your argument, but perhaps a bit more consideration around the topic in general would be a good idea?
There was a problem hiding this comment.
Based on this news: https://github.com/carllerche/http I would like to withdraw this RFC, perhaps the answer here is to rather get a quality network types library together and then rally around it's by lobbying authors of other crates. Thanks for considering it though!
Can I just go ahead and close it?
There was a problem hiding this comment.
Having polled a couple of developers there is one concern about 'non-complex type' crates as an alternative. the http crate has immense value, and is packed full of consts and enums that would take any developer a lot of time to bootstrap.
Would people opt-in to 'bloating' their Cargo.toml files (and imports) just to have a re-usable simple type? MacAddr48 is just a [u8; 6] - as a coder it might just be simpler to do the latter than go to the trouble of finding a crate. To me this is an argument for inclusion in some sort of larger, standardized library, even if it isn't std itself?
There was a problem hiding this comment.
@stephanbuys I'd want to use the common type if one of my dependencies did, or if I was aware of the common crate and it had useful functionality (e.g. helpful instances for comparison and pretty-printing).
|
Yes.
…On Aug 1, 2017 10:37 AM, "Stephan Buys" ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In 0000-net-mac-address.md
<#2082 (comment)>:
> +- Feature Name: `net_address_mac`
+- Start Date: 2017-07-26
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+[summary]: #summary
+
+Add a media access control address (MAC) address datatype, `std::net::MacAddr48` to `std::net`.
+
+# Motivation
+[motivation]: #motivation
+
+Currently there is no standard way to communicate physical (or ethernet) addresses when doing network related development in rust, even though `std::net::IpAddrV4` and `std::net::IpAddrV6` exist. The MAC address is, however, a regularly occurring data-structure when doing any type of network related development.
+
+There is also a proliferation of implementations which are not compatible with each other, forcing developers to manually implement the data type again and again, reducing the opportunity for code re-use and convenience. `nom`[1], `libpnet`[2] and `diesel`[3] being a couple of examples.
Based on this news: https://github.com/carllerche/http I would like to
withdraw this RFC, perhaps the answer here is to rather get a quality
network types library together and then rally around it's by lobbying
authors of other crates. Thanks for considering it though!
Can I just go ahead and close it?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2082 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AApc0joRu8ayKRLBrL0P3FFl_ZsyUwOYks5sTtW9gaJpZM4OjngI>
.
|
|
Ok, withdrawing this RFC, perhaps at a point in the future a collection of mature type crates with conversion/helper functions would be considered for consolidation and inclusion in |
Having worked with networking code in Rust for a couple of months now, I was inspired to write this RFC after encountering yet another implementation of MAC addresses in
diesel.rs:-)This RFC proposes that a datatype
MacAddr48be added to the standard library so that this common type of networking data can be handled easily and predictably between crates.Rendered