Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 12 17:37

    github-actions[bot] on gh-pages

    API Guidelines @ rust-lang/api-… (compare)

  • Jun 12 17:37

    dtolnay on master

    C-DTOR: Clarify that `Drop` sho… Merge pull request #263 from jo… (compare)

  • Jun 12 17:37
    dtolnay closed #263
  • Jun 12 16:49
    joshtriplett edited #263
  • Jun 12 16:48
    joshtriplett synchronize #263
  • Jun 12 11:24
    dtolnay closed #122
  • Jun 12 08:11
    joshtriplett opened #263
  • Jun 12 08:06

    github-actions[bot] on gh-pages

    API Guidelines @ rust-lang/api-… (compare)

  • Jun 12 08:06

    joshtriplett on master

    Replace "task failure" with "pa… Merge pull request #261 from Pa… (compare)

  • Jun 12 08:06
    joshtriplett closed #261
  • Apr 30 02:53

    github-actions[bot] on gh-pages

    API Guidelines @ rust-lang/api-… (compare)

  • Apr 30 02:53

    dtolnay on master

    Update GitHub Actions actions/c… Merge pull request #262 from dt… (compare)

  • Apr 30 02:53
    dtolnay closed #262
  • Apr 30 02:50
    dtolnay opened #262
  • Mar 02 15:12
    PatchMixolydic opened #261
  • Dec 27 2021 18:46
    NeverGivinUp commented #257
  • Dec 27 2021 12:35
    NeverGivinUp opened #257
  • Dec 01 2021 03:17
    dtolnay closed #256
  • Dec 01 2021 03:01
    pie-flavor opened #256
  • Nov 26 2021 05:52
    KodrAus commented #252
David Tolnay
@dtolnay
i updated the one in the header
QuietMisdreavus
@QuietMisdreavus
changing the title (the first line) of the document changes its url
Aaron Turon
@aturon
@dtolnay i hope to pitch in on this effort too — if there’s any place where you think i could be particularly helpful, please let me know
David Tolnay
@dtolnay
thanks @aturon, the most valuable would be if you can weigh in on some of the "soliciting opinions" issues https://github.com/rust-lang-nursery/api-guidelines/issues?q=is%3Aissue+is%3Aopen+label%3A%22soliciting+opinions%22
Aaron Turon
@aturon
cool! will do
Charles Lew
@crlf0710

Hi, not sure if this is a proper place to ask, but i'm looking for some "insight"s and guidelines of the trait system.

What kind of roles should traits play? I've seen adjectives "Sized", nouns "Future" "Sync", verbs "Send" "Convert" "Borrow", prepositions "From" "To" "AsRef". Not to say some people are even abusing trait inheritance trying to build type taxonomy using trait inheritance. Are traits truly neutral to these usages? Or should there be some guidelines for when and how?

David Tolnay
@dtolnay
great question @crlf0710
we have been trying to figure this out in rust-lang-nursery/api-guidelines#28
i would prefer not to be prescriptive about what you are allowed to use traits for
rather, maybe the guideline should list the various grammar categories with examples, and recommend using the one that has traits most similar to your trait
Charles Lew
@crlf0710
@dtolnay great, thanks. i'll try to summarize some current usages under #28.
Charles Lew
@crlf0710
i've opened pr rust-lang-nursery/api-guidelines#126. Let me know if anything's inappropriate or missing!
Aaron Turon
@aturon
@dtolnay hey — just wanted to check in on this WG in general; how are things looking?
Eduardo Pinho
@Enet4
Good day! I am currently facing a small method naming dilemma.
I have a constructor method for type Foo which uses a Bar, but also returns a Baz alongside the Foo (as in, a Result<(Foo, Baz)>). How should one name this method?
Eduardo Pinho
@Enet4
I mean, one would expect the prefix with_. But with_bar_and_baz is misleading, and with_bar_with_baz sounds crazy. I've been thinking about with_bar_plus_baz, but I'd certainly appreciate some opinions.
David Tolnay
@dtolnay
@Enet4 hmm, i haven't seen that sort of situation in my own code
but i found one example in the standard library https://doc.rust-lang.org/std/sync/mpsc/fn.channel.html
which is a constructor for two types that are somehow related
in your case would it be possible to make this a module-level function rather than inside of impl Foo?
David Tolnay
@dtolnay
can you say more about what specific types are involved here? it's tricky to make a good recommendation about Foo and Bar in the abstract
Eduardo Pinho
@Enet4
@dtolnay It's for the nifti crate. Reading a .img file here should yield a header extension sequence followed by the actual volume data. https://docs.rs/nifti/0.3.1/nifti/volume/inmem/struct.InMemNiftiVolume.html#method.from_file_with_extensions
Admittedly, this might not make a good static method. And now I wonder whether it should be public, since I already have another data type which reads everything.
Yaroslav Skopets
@yskopets

Hi guys,
I have a question about guidelines on use of errors in the API of a library.
I’m developing a library in Rust and, naturally, it has to return errors from its API.
I followed C-GOOD-ERR advice and created error types specific to my domain (some of them are structs, some enums).
However, during the code review I was told that I’m doing it wrong, C-GOOD-ERR is legacy, API guidelines are outdated and what I should do is to replace my struct/enum errors with ad-hoc strings inside Result#context("error message").
I tried to argue that Result#context("error message") is complementary and cannot be a substitute for structured errors, especially when returned by the library. But, again, I’m told I’m wrong.

Could you please help me understand why struct/enum errors are wrong ?
Is Result#context(“error message”) indeed a substitute for them ?
Are you planning to update guidelines to favour Result#context(“error message”) over typed errors ?
Thanks in advance!

Ryo Hirayama
@ryo33
We should add this to the list: "Tuple struct/variant means the name describes the contained value". So Int(0) is ok, but Add("ryo") isn't (this should be Add { name: "ryo" }), and Int { value: 0 } or Int { int: 0 } is confusing for redundancy.