-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Add std::net::MacAddr48 to std::net #2082
Closed
Closed
Changes from all commits
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
f367689
Draft 1, net-mac-address
stephanbuys ac1f03f
Merge branch 'master' of https://github.com/rust-lang/rfcs
stephanbuys 6ed48b6
Couple of refinements
stephanbuys b32c039
Reformat references
stephanbuys 7eaba9e
Fix the Feature Name
stephanbuys ef07c23
Update 0000-net-mac-address.md
stephanbuys File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,72 @@ | ||
- 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. | ||
|
||
[1] https://github.com/moosingin3space/pktparse-rs/blob/master/src/ethernet.rs | ||
|
||
[2] https://github.com/libpnet/libpnet/blob/master/src/util.rs | ||
|
||
[3] http://docs.diesel.rs/diesel/pg/types/sql_types/struct.MacAddr.html | ||
|
||
|
||
# Detailed design | ||
[design]: #detailed-design | ||
|
||
It is proposed that the existing `crate` `eui48` be used (https://crates.io/crates/eui48) as a basis for this RFC, thus the code below is copied directly from that implementation. | ||
|
||
The following struct would be added to `std::net`: | ||
|
||
|
||
``` | ||
|
||
/// A 48-bit (6 byte) buffer containing the EUI address | ||
/// See: https://en.wikipedia.org/wiki/MAC_address | ||
pub const EUI48LEN: usize = 6; | ||
pub type Eui48 = [u8; EUI48LEN]; | ||
|
||
/// A MAC address (EUI-48) | ||
#[derive(Copy, Clone)] | ||
pub struct MacAddr48 { | ||
/// The 48-bit number stored in 6 bytes | ||
eui: Eui48, | ||
} | ||
|
||
``` | ||
|
||
It is proposed that most of the functions and `impl` from the `eui48` crate be included in `std::net::MacAddr48`, although there are open questions as to the need to support the `eui48` and `eui64` datatypes as those are trademarked by the IEEE, and MAC addresses are most commonly encountered in the ecosystem as well as the functions depending on Serde. | ||
|
||
# How We Teach This | ||
[how-we-teach-this]: #how-we-teach-this | ||
|
||
Networking related code is not directly addressed in any of the official rust books, that said, an effort could be made to contact some of the larger crates to encourage them to adopt the `std::net` structs. | ||
|
||
It might be a good idea to investigate adding some examples to the rust cookbook, at https://brson.github.io/rust-cookbook/net.html#ex-random-port-tcp, altough the authors there would need to approve the topics and at this point no items in the standard library expose or use MAC addresses (based on a brief search), the target audience for this extension would primarily be other crate authors. | ||
|
||
# Drawbacks | ||
[drawbacks]: #drawbacks | ||
|
||
Extending the standard library is something that should be very carefully considered before undertaking any changes, it increases the maintenance load on the relevant teams. | ||
|
||
# Alternatives | ||
[alternatives]: #alternatives | ||
|
||
Promote or "bless" a standard crate for MAC addresses and spread the word to the large crates (such as diesel, libpnet, etc) and attempt to convince them to use it. | ||
|
||
# Unresolved questions | ||
[unresolved]: #unresolved-questions | ||
|
||
Should we stop at MAC addresses? There are other networking datatypes to be included? | ||
Should we add the `Serde` dependent serialization and deserialization `fn`'s? |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This exact argument applies equally to dozens if not hundreds of types. If I took this this RFC and find/replaced
MacAddr48
withUuid
orPath
orPolygon
orRgb
orRgba
orNetmask
orQuaternion
orMatrix
orVector
orTraceId
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 ofconst
s andenum
s 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'tstd
itself?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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).