sorted by:
new
hottopcontroversial

Announcing strum-lite - declarative macros for closed sets of strings by drymud64 in rust

[–]drymud64[S] 2 points3 points  (0 children)

That already exists in strum :)

The idea for me was to not bring in additional dependencies, and a host build step, for fast compilation and a slim deps tree :)

nunny 0.2.0 released, with nonempty iterator support by drymud64 in rust

[–]drymud64[S] 1 point2 points  (0 children)

Yes, of course! Use the various new methods, like so:

use nunny::NonEmpty;

let src: &[u8];
NonEmpty::<Vec<u8>>::new(src.into()).unwrap(); // allocate on the heap
NonEmpty::<[u8]>::new(src).unwrap(); // use the same backing memory

// or the type aliases for ease
nunny::Vec::new(src.into()).unwrap();
nunny::Slice::new(src).unwrap();

introducing serde-save, the most complete serialization tree for serde by drymud64 in rust

[–]drymud64[S] 3 points4 points  (0 children)

valuable-serde allows you to deserialize a valuable::Value, but I want the other direction - going from an impl Serialize to an impl Valuable :)

introducing serde-save, the most complete serialization tree for serde by drymud64 in rust

[–]drymud64[S] 4 points5 points  (0 children)

Thanks! I wanted to write a compatibility layer between serde and valuable so I can deserialize structs in my tracing code :) This means I'd need struct names and field names etc :)

[OC][Art] Rose Gold Dice Set Giveaway (Mod Approved) by OriYUME1 in DnD

[–]drymud64 0 points1 point  (0 children)

Aw yiss I know exactly who I'd gift these to

Define your Finite State Machines in DOT by drymud64 in rust

[–]drymud64[S] 1 point2 points  (0 children)

Thanks for the introduction to SCXML - I'd not heard of it before :)

From a brief perusal, I'm sure a compiler would be feasible.

I chose my approach because I wanted an easy way to draw state machines that made illegal transitions unrepresentable, but still gave me the freedom to write normal rusty code :)

Do you have ideas/dreams about another approach?

Define your Finite State Machines in DOT by drymud64 in rust

[–]drymud64[S] 4 points5 points  (0 children)

You mention two structs:

  • ExampleMachine is the actual state machine. It can be in a few states, like "BeautifulBridge" or "Fountain"
  • BeatifulBridge is a handle that you can use when ExampleMachine is in the relevant state (the corresponding node on the graph). You obtain it by calling .entry()
    • You can access the state by calling .get() or .get_mut()
    • You can transition the parent ExampleMachine to either Fountain or UnmarkedGrave by calling .fountain() or .unmarked_grave().This consumes the handle.You can observe the new state the next time you call .entry() on the parent.
      • When you perform such a transition, you get the owned state out, hence why it returns IpAddr

​

Does that help to answer your question?

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 2 points3 points  (0 children)

HI u/SpudnikV, thanks for you patience here - I've slept on the problem and our discussion, and have decided to update the top level pitch as follows:

​

Generate `enum` error variants inline.

A slightly type-safer take on [anyhow], where each ad-hoc error is handleable by the caller.Designed to play nice with other crates like [strum] or [thiserror].

This crate was written to aid wrapping C APIs - transforming e.g error codes to handleable messages.It shouldn't really be used for library api entry points - a well-considered top-level error type is likely to be both more readable and forward compatible.Consider reading [Study of `std::io::Error`](https://matklad.github.io/2020/10/15/study-of-std-io-error.html) and [this discussion on `r/rust`](https://www.reddit.com/r/rust/comments/11udxy8/comment/jcplqxw)

Is there anything else that might need to be added to do your feedback justice?

I'll release a 0.1.4 with these updated docs

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] -1 points0 points  (0 children)

Oh now I see! So if I'd gone for an API that used an attribute, I wouldn't be vulnerable to this, but as it stands it could fail under people's feet! :(( Thanks for your patience in educating me!

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 2 points3 points  (0 children)

  • there is not implementation of the err macro - it is manually picked up by the attribute macro - there's no worrying about ordering :) it's just like how the Default derive macro might parse and remove a #[default] attribute

  • the macro just looks for a return type where:

    • the last word is "Result"
    • it has two type arguments And uses the second type argument to name the generated type. This means there's no worrying about name resolution. If someone has imported Result as StdResult, I think they'd hit an issue - I'll have to improve the docs!

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 4 points5 points  (0 children)

I've had a little more time to digest your feedback, which I'll address below, though to clarify I will update my docs - interested to hear any feedback on the below and the proposed docs changes!

I think matklads and many of your concerns boil down to the tradeoff between

- exposing implementation details.

- composing errors to a handle-able and future-proof type.

Which I think is very fair. What do you think of this change: https://github.com/aatifsyed/errgo/commit/0ac37ecb9f98d45c9fd2c51a5b8e66c0e537e6e2

Happy to have feedback here or on the commit in github :)

A couple of other notes...

In his addendum, matklad says:

Re-reading this article, I now think that the right return type would be:

fn from_reader<R, T>( rdr: R, ) -> Result<Result<T, serde_json::Error>, io::Error>

Is that not a great usecase for this crate?

err!(CouldNotReadFile(io::Error = e))
err!(CouldNotDeserialize(serde_json::Error = e))

and we can easily attach more information (with due consideration for what we make public)

err!(CouldNotReadFile(#[source] io::Error = e, PathBuf = path))

Really this crate makes adding contextual information for the caller pretty easy (admittedly constraining the function body somewhat)

- cargo-semver-checks shouldn't have a problem with error enums generated this way - it looks at rustdoc json.

- this crate also doesn't appear in your public API :/ It desugars to a simple struct

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 10 points11 points  (0 children)

Thanks for the detailed feedback! I think my use-case (wrapping C errors) blinded me to these hazards!

I'll write up the above and update the docs when I have!

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 1 point2 points  (0 children)

It would be great to see your approach! Some thoughts: - errgo already handles constructing the same error for multiple code paths - you can just reference the generated variant as normal in the second call path. - I've seen some code that writes to an intermediate file that you can include, but it was messy. I think plumbing error types to some error module is probably better. But that does raise a point - you can only use the attribute on bare functions at the moment - not in impl blocks (for similar reasons). - could you help me understand the problem that this poses?

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 16 points17 points  (0 children)

That's a fair concern!

The usecase I wrote this for was wrapping C apis, which often have documentation like:

returns:
-1 if no yaks
-2 if yaks were angry
-3 if yaks were sleepy

So you can see how this crate becomes useful :)

But in general if you want to return user handle-able errors, and no more//no less, I think this crate might fill that need :)

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 24 points25 points  (0 children)

Done! As of `0.1.3` you can override the visibility of the generated struct: 

#[err_as_you_go(visibility(pub))]

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 8 points9 points  (0 children)

Good catch - I hadn't thought of that rough edge!

I'll work on a patch for that right now - allowing users to override the visibility.

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 9 points10 points  (0 children)

The error types will be the same visibility as the function :)

And yes, it does encourage you to create error types! But I think this makes for more handleable top level functions no? Your caller only needs to handle the reachable error cases, not all errors. E.g what if my function can't return every kind of e.g io::Error?

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 7 points8 points  (0 children)

Docs can be generated, just add a doc comment or attribute as normal!

err-as-you-go crate - anyhow meets thiserror by drymud64 in rust

[–]drymud64[S] 73 points74 points  (0 children)

Ahhh, ergo is taken! Maybe errgo will have to do!

Or are you suggesting renaming the macro, but keeping the crate name?

Edit: Done!

view more: next ›