gh-uuid-rs/uuid

Watch

Fork

You've already forked uuid

Code Issues 10 Pull requests 2 Releases Activity

Ensure that we are complying with Rust API Guidelines #191

New issue

Closed

opened 2018-03-30 17:18:56 -05:00 by kinggoesgaming · 2 comments

kinggoesgaming commented

2018-03-30 17:18:56 -05:00

(Migrated from github.com)

You can visit https://rust-lang-nursery.github.io/api-guidelines/ to get more information on each guideline.
If we are not complying with any point, open a separate issue and link the issue as the tracking issue here.
If a point is not applicable to uuid put two ~~ around it to cross it out.

Naming (crate aligns with Rust naming conventions)
- Casing conforms to RFC 430 (C-CASE)
- Ad-hoc conversions follow as_, to_, into_ conventions (C-CONV)
- Getter names follow Rust convention (C-GETTER)
- ~~Methods on collections that produce iterators follow iter, iter_mut, into_iter (C-ITER)~~
  - We do not have any collections
- ~~Iterator type names match the methods that produce them (C-ITER-TY)~~
  - We do not have any iterator types.
- Feature names are free of placeholder words (C-FEATURE)
- Names use a consistent word order (C-WORD-ORDER)
Interoperability (crate interacts nicely with other library functionality)
- Types eagerly implement common traits (C-COMMON-TRAITS)
  - Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash, Debug,
    Display, Default
- Conversions use the standard traits From, AsRef, AsMut (C-CONV-TRAITS)
- Collections implement FromIterator and Extend (C-COLLECT)
  - We do not have any collections.
- Data structures implement Serde's Serialize, Deserialize (C-SERDE)
- Types are Send and Sync where possible (C-SEND-SYNC)
- Error types are meaningful and well-behaved (C-GOOD-ERR)
- Binary number types provide Hex, Octal, Binary formatting (C-NUM-FMT)
  - Uuid and associated adapters dont need Octal and Binary formatting.
- ~~Generic reader/writer functions take R: Read and W: Write by value (C-RW-VALUE)~~
  - We do not have reader/writer functions
Macros (crate presents well-behaved macros)
- ~~Input syntax is evocative of the output (C-EVOCATIVE)~~
  - We do not have any public macros
- ~~Macros compose well with attributes (C-MACRO-ATTR)~~
  - We do not have any public macros
- ~~Item macros work anywhere that items are allowed (C-ANYWHERE)~~
  - We do not have any public macros
- ~~Item macros support visibility specifiers (C-MACRO-VIS)~~
  - We do not have any public macros
- ~~Type fragments are flexible (C-MACRO-TY)~~
  - We do not have any public macros
Documentation (crate is abundantly documented)
- Crate level docs are thorough and include examples (C-CRATE-DOC)
- All items have a rustdoc example (C-EXAMPLE)
- Examples use ?, not try!, not unwrap (C-QUESTION-MARK)
- Function docs include error, panic, and safety considerations (C-FAILURE)
- Prose contains hyperlinks to relevant things (C-LINK)
- Cargo.toml includes all common metadata (C-METADATA)
  - authors, description, license, homepage, documentation, repository,
    readme, keywords, categories
- Crate sets html_root_url attribute "https://docs.rs/CRATE/X.Y.Z" (C-HTML-ROOT)
- Release notes document all significant changes (C-RELNOTES)
- Rustdoc does not show unhelpful implementation details (C-HIDDEN)
Predictability (crate enables legible code that acts how it looks)
- ~~Smart pointers do not add inherent methods (C-SMART-PTR)~~
  - We do not have smart pointers
- Conversions live on the most specific type involved (C-CONV-SPECIFIC)
- Functions with a clear receiver are methods (C-METHOD)
- Functions do not take out-parameters (C-NO-OUT)
- ~~Operator overloads are unsurprising (C-OVERLOAD)~~
  - We do not have any types with operator overloading
- ~~Only smart pointers implement Deref and DerefMut (C-DEREF)~~
  - We do not have smart pointers
- Constructors are static, inherent methods (C-CTOR)
Flexibility (crate supports diverse real-world use cases)
- Functions expose intermediate results to avoid duplicate work (C-INTERMEDIATE)
- Caller decides where to copy and place data (C-CALLER-CONTROL)
- Functions minimize assumptions about parameters by using generics (C-GENERIC)
- Traits are object-safe if they may be useful as a trait object (C-OBJECT)
Type safety (crate leverages the type system effectively)
- Newtypes provide static distinctions (C-NEWTYPE)
- Arguments convey meaning through types, not bool or Option (C-CUSTOM-TYPE)
- ~~Types for a set of flags are bitflags, not enums (C-BITFLAG)~~
  - We don't have any flags
- Builders enable construction of complex values (C-BUILDER)
Dependability (crate is unlikely to do the wrong thing)
- Functions validate their arguments (C-VALIDATE)
- Destructors never fail (C-DTOR-FAIL)
- ~~Destructors that may block have alternatives (C-DTOR-BLOCK)~~
  - We don't have destructors that may block
Debuggability (crate is conducive to easy debugging)
- All public types implement Debug (C-DEBUG)
- Debug representation is never empty (C-DEBUG-NONEMPTY)
Future proofing (crate is free to improve without breaking users' code)
- Sealed traits protect against downstream implementations (C-SEALED)
- Structs have private fields (C-STRUCT-PRIVATE)
- Newtypes encapsulate implementation details (C-NEWTYPE-HIDE)
- Data structures do not duplicate derived trait bounds (C-STRUCT-BOUNDS)
Necessities (to whom they matter, they really matter)
- Public dependencies of a stable crate are stable (C-STABLE)
- Crate and its dependencies have a permissive license (C-PERMISSIVE)

* You can visit https://rust-lang-nursery.github.io/api-guidelines/ to get more information on each guideline. * If we are not complying with any point, open a separate issue and link the issue as the tracking issue here. * If a point is not applicable to `uuid` put two `~~` around it to cross it out. --- - **Naming** *(crate aligns with Rust naming conventions)* - [x] Casing conforms to RFC 430 (C-CASE) - [x] Ad-hoc conversions follow `as_`, `to_`, `into_` conventions (C-CONV) - [x] Getter names follow Rust convention (C-GETTER) - [x] ~~Methods on collections that produce iterators follow `iter`, `iter_mut`, `into_iter` (C-ITER)~~ - We do not have any collections - [x] ~~Iterator type names match the methods that produce them (C-ITER-TY)~~ - We do not have any iterator types. - [x] Feature names are free of placeholder words (C-FEATURE) - [x] Names use a consistent word order (C-WORD-ORDER) - **Interoperability** *(crate interacts nicely with other library functionality)* - [x] Types eagerly implement common traits (C-COMMON-TRAITS) - `Copy`, `Clone`, `Eq`, `PartialEq`, `Ord`, `PartialOrd`, `Hash`, `Debug`, `Display`, `Default` - [x] Conversions use the standard traits `From`, `AsRef`, `AsMut` (C-CONV-TRAITS) - [x] Collections implement `FromIterator` and `Extend` (C-COLLECT) - We do not have any collections. - [x] Data structures implement Serde's `Serialize`, `Deserialize` (C-SERDE) - [ ] Types are `Send` and `Sync` where possible (C-SEND-SYNC) - [x] Error types are meaningful and well-behaved (C-GOOD-ERR) - [x] Binary number types provide `Hex`, `Octal`, `Binary` formatting (C-NUM-FMT) - `Uuid` and associated adapters dont need `Octal` and `Binary` formatting. - [x] ~~Generic reader/writer functions take `R: Read` and `W: Write` by value (C-RW-VALUE)~~ - We do not have reader/writer functions - **Macros** *(crate presents well-behaved macros)* - [x] ~~Input syntax is evocative of the output (C-EVOCATIVE)~~ - We do not have any public macros - [x] ~~Macros compose well with attributes (C-MACRO-ATTR)~~ - We do not have any public macros - [x] ~~Item macros work anywhere that items are allowed (C-ANYWHERE)~~ - We do not have any public macros - [x] ~~Item macros support visibility specifiers (C-MACRO-VIS)~~ - We do not have any public macros - [x] ~~Type fragments are flexible (C-MACRO-TY)~~ - We do not have any public macros - **Documentation** *(crate is abundantly documented)* - [x] Crate level docs are thorough and include examples (C-CRATE-DOC) - [ ] All items have a rustdoc example (C-EXAMPLE) - [ ] Examples use `?`, not `try!`, not `unwrap` (C-QUESTION-MARK) - [ ] Function docs include error, panic, and safety considerations (C-FAILURE) - [ ] Prose contains hyperlinks to relevant things (C-LINK) - [x] Cargo.toml includes all common metadata (C-METADATA) - authors, description, license, homepage, documentation, repository, readme, keywords, categories - [x] Crate sets html_root_url attribute "https://docs.rs/CRATE/X.Y.Z" (C-HTML-ROOT) - [ ] Release notes document all significant changes (C-RELNOTES) - [ ] Rustdoc does not show unhelpful implementation details (C-HIDDEN) - **Predictability** *(crate enables legible code that acts how it looks)* - [x] ~~Smart pointers do not add inherent methods (C-SMART-PTR)~~ - We do not have smart pointers - [ ] Conversions live on the most specific type involved (C-CONV-SPECIFIC) - [ ] Functions with a clear receiver are methods (C-METHOD) - [ ] Functions do not take out-parameters (C-NO-OUT) - [x] ~~Operator overloads are unsurprising (C-OVERLOAD)~~ - We do not have any types with operator overloading - [x] ~~Only smart pointers implement `Deref` and `DerefMut` (C-DEREF)~~ - We do not have smart pointers - [x] Constructors are static, inherent methods (C-CTOR) - **Flexibility** *(crate supports diverse real-world use cases)* - [ ] Functions expose intermediate results to avoid duplicate work (C-INTERMEDIATE) - [ ] Caller decides where to copy and place data (C-CALLER-CONTROL) - [ ] Functions minimize assumptions about parameters by using generics (C-GENERIC) - [ ] Traits are object-safe if they may be useful as a trait object (C-OBJECT) - **Type safety** *(crate leverages the type system effectively)* - [ ] Newtypes provide static distinctions (C-NEWTYPE) - [ ] Arguments convey meaning through types, not `bool` or `Option` (C-CUSTOM-TYPE) - [x] ~~Types for a set of flags are `bitflags`, not enums (C-BITFLAG)~~ - We don't have any flags - [x] Builders enable construction of complex values (C-BUILDER) - **Dependability** *(crate is unlikely to do the wrong thing)* - [ ] Functions validate their arguments (C-VALIDATE) - [x] Destructors never fail (C-DTOR-FAIL) - [x] ~~Destructors that may block have alternatives (C-DTOR-BLOCK)~~ - We don't have destructors that may block - **Debuggability** *(crate is conducive to easy debugging)* - [x] All public types implement `Debug` (C-DEBUG) - [x] `Debug` representation is never empty (C-DEBUG-NONEMPTY) - **Future proofing** *(crate is free to improve without breaking users' code)* - [ ] Sealed traits protect against downstream implementations (C-SEALED) - [x] Structs have private fields (C-STRUCT-PRIVATE) - [x] Newtypes encapsulate implementation details (C-NEWTYPE-HIDE) - [ ] Data structures do not duplicate derived trait bounds (C-STRUCT-BOUNDS) - **Necessities** *(to whom they matter, they really matter)* - [x] Public dependencies of a stable crate are stable (C-STABLE) - [ ] Crate and its dependencies have a permissive license (C-PERMISSIVE)

👍 1

KodrAus commented

2018-04-08 16:53:41 -05:00

(Migrated from github.com)

It would be good to run through this when we're ready to release a 1.0 👍

It would be good to run through this when we're ready to release a `1.0` :+1:

👍 2

kinggoesgaming commented

2019-10-21 19:11:08 -05:00

(Migrated from github.com)

@KodrAus @Dylan-DPC We should get these sorted out now...

right now 33 points out of 55 are checked.. lets make it 55

edit: make it 34

@KodrAus @Dylan-DPC We should get these sorted out now... right now 33 points out of 55 are checked.. lets make it 55 edit: make it 34

No Branch/Tag specified

main

archive/20260925T210141Z-rescue/jaideeppyne/fix/urn-prefix-case-insensitive

archive/20260925T210141Z-rescue/youdie006/systemtime-nanos-carry

breaking-2

0.8.x

v1.28.0

v1.27.0

v1.26.1

v1.26.0

1.25.0

v1.24.1

v1.24.0

v1.23.5

v1.23.4

v1.23.3

v1.23.2

v1.23.1

v1.23.0

v1.22.0

v1.21.0

v1.20.0

v1.19.0

v1.18.1

v1.18.0

v1.17.0

v1.16.0

v1.15.1

v1.15.0

v1.14.0

v1.13.2

1.13.1

1.13.0

1.12.1

1.12.0

1.11.1

1.11.0

1.10.0

1.9.1

1.9.0

1.8.0

1.7.0

1.6.1

1.6.0

1.5.0

1.4.1

1.4.0

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.2

1.2.1

1.2.0

1.1.2

1.1.1

1.1.0

1.0.0

1.0.0-alpha.1

0.8.2

0.8.1

0.8.0

0.7.4

0.7.3

0.7.2

0.7.1

0.7.0

0.7.0-beta

0.6.5

0.6.4

0.6.3

0.6.2

0.6.1

0.6.0

0.6.0-beta

0.5.1

0.5.0

0.4.0

0.3.1

0.3.0

0.2.3

0.2.2

0.2.1

0.2.0

Labels

Clear labels

breaking

This causes a breaking change and will be merged to breaking branch.

bug

dependencies

Pull requests that update a dependency file

good first issue

help wanted

unstable

Tracking issue for an unstable optional dependency

No labels

Milestone

Clear milestone

No items

No milestone

0.8.0

Assignees

Clear assignees

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

gh-uuid-rs/uuid#191

Reference in a new issue

Repository

gh-uuid-rs/uuid

Title

Body

No description provided.

Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?

Rows
Columns