{"action":"created","issue":{"url":"https://api.github.com/repos/BurntSushi/byteorder/issues/27","labels_url":"https://api.github.com/repos/BurntSushi/byteorder/issues/27/labels{/name}","comments_url":"https://api.github.com/repos/BurntSushi/byteorder/issues/27/comments","events_url":"https://api.github.com/repos/BurntSushi/byteorder/issues/27/events","html_url":"https://github.com/BurntSushi/byteorder/issues/27","id":70047462,"number":27,"title":"Improve WriteBytesExt API","user":{"login":"nwin","id":949560,"avatar_url":"https://avatars.githubusercontent.com/u/949560?v=3","gravatar_id":"","url":"https://api.github.com/users/nwin","html_url":"https://github.com/nwin","followers_url":"https://api.github.com/users/nwin/followers","following_url":"https://api.github.com/users/nwin/following{/other_user}","gists_url":"https://api.github.com/users/nwin/gists{/gist_id}","starred_url":"https://api.github.com/users/nwin/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nwin/subscriptions","organizations_url":"https://api.github.com/users/nwin/orgs","repos_url":"https://api.github.com/users/nwin/repos","events_url":"https://api.github.com/users/nwin/events{/privacy}","received_events_url":"https://api.github.com/users/nwin/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-04-22T07:31:01Z","updated_at":"2015-04-23T01:55:45Z","closed_at":null,"body":"At the moment the byteorder crate uses a enum to generalize over the endianness and the method name to select the type. Both is not very ergonomic to use. I propose the following interface:\r\n\r\n\ttrait WriteBytesExt<T> {\r\n\t\tfn write_le(&mut self, n: T) -> io::Result<()>;\r\n\t\tfn write_be(&mut self, n: T) -> io::Result<()>;\r\n\t}\r\n\t\r\n\timpl<W> WriteBytesExt<u8> for W where W: Write {\r\n\t\tfn write_le(&mut self, n: u8) -> io::Result<()> {\r\n\t\t\t....\r\n\t\t}\r\n\t\t....\r\n\t}\r\n\r\nFirst of all it gets rid of the enum. Since the enum is purely a compile time parameter it cannot be used for dynamic dispatch. This is as good or bad as having it directly the method name. Thus I do not see the point of having it. Secondly it gets rid of the redundant type name in the signature.\r\n\r\nThis shortens the method call significantly\r\n\r\n    w.write_u16::<LittleEndian>(42u16)\r\n\r\nbecomes\r\n\r\n    w.write_le(42u16)\r\n\r\nMy two points are:\r\n\r\n 1. The type in the method signature carries redundant information.\r\n 2. The enum type parameter does not provide any benefit for the user.\r\n 3. Enums are most useful for runtime polymorphism. Thus, as the enum variants are no types these `*BytesExt` traits cannot be use to write generic code that abstracts over endianness. Again no benefit for the user.\r\n    "},"comment":{"url":"https://api.github.com/repos/BurntSushi/byteorder/issues/comments/95387851","html_url":"https://github.com/BurntSushi/byteorder/issues/27#issuecomment-95387851","issue_url":"https://api.github.com/repos/BurntSushi/byteorder/issues/27","id":95387851,"user":{"login":"TyOverby","id":573215,"avatar_url":"https://avatars.githubusercontent.com/u/573215?v=3","gravatar_id":"","url":"https://api.github.com/users/TyOverby","html_url":"https://github.com/TyOverby","followers_url":"https://api.github.com/users/TyOverby/followers","following_url":"https://api.github.com/users/TyOverby/following{/other_user}","gists_url":"https://api.github.com/users/TyOverby/gists{/gist_id}","starred_url":"https://api.github.com/users/TyOverby/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/TyOverby/subscriptions","organizations_url":"https://api.github.com/users/TyOverby/orgs","repos_url":"https://api.github.com/users/TyOverby/repos","events_url":"https://api.github.com/users/TyOverby/events{/privacy}","received_events_url":"https://api.github.com/users/TyOverby/received_events","type":"User","site_admin":false},"created_at":"2015-04-23T01:55:45Z","updated_at":"2015-04-23T01:55:45Z","body":"I use `byteorder` in [bincode](https://github.com/TyOverby/bincode) and while I don't use the functionality yet, once default-types for functions land I plan on using the current implementation to allow my users to write code like this:\r\n\r\n```rust\r\nbincode::encode(&my_struct); // default to network byte order\r\nbincode::encode::<LittleEndian>(&my_struct); // specify endianness\r\n// Use other endianness like above\r\n```\r\n\r\nThe benefit to the way that @BurntSushi currently implements it is that having these functions called with different endianness imposes no runtime lookup, which is very important to bincode."}}