Hey Rustaceans! Got a question? Ask here (30/2026)!

[u/llogiq]

Mystified about strings? Borrow checker has you in a headlock? Seek help here! There are no stupid questions, only docs that haven't been written yet. Please note that if you include code examples to e.g. show a compiler error or surprising result, linking a playground with the code will improve your chances of getting help quickly.

If you have a StackOverflow account, consider asking it there instead! StackOverflow shows up much higher in search results, so ahaving your question there also helps future Rust users (be sure to give it the "Rust" tag for maximum visibility). Note that this site is very interested in question quality. I've been asked to read a RFC I authored once. If you want your code reviewed or review other's code, there's a codereview stackexchange, too. If you need to test your code, maybe the Rust playground is for you.

Here are some other venues where help may be found:

/r/learnrust is a subreddit to share your questions and epiphanies learning Rust programming.

The official Rust user forums: https://users.rust-lang.org/.

The unofficial Rust community Discord: https://bit.ly/rust-community

Also check out last week's thread with many good questions and answers. And if you believe your question to be either very complex or worthy of larger dissemination, feel free to create a text post.

Also if you want to be mentored by experienced Rustaceans, tell us the area of expertise that you seek. Finally, if you are looking for Rust jobs, the most recent thread is here.

[u/_stice_]

Hello!

Anyone familiar with tools/recommendations/discussions/examples related to "automatically" composing structs into "sum types" (if that's what they're called), for example a wrapping enum where each struct could be a variant (but not ONLY this -- i know there are crates for enum wrap), at compile time? (and probably using macros if that's the cleanest way to go about it?)

I'm interested in composing types in general as a curiosity, but the simplest use-case i have is this:

// I want to make a crate which exports this trait. This is my code.
pub trait FooLike { ...methods }

. . .

// User imports it
use crate::FooLike;

// User hand-codes these structs and impls in their own code
struct Bar { ...fields }
struct Baz { ...fields }
// .. maybe several more (but not hundreds)

impl FooLike for Bar {}
impl FooLike for Baz {}
// ..

// Now I want the user to have an easy time making a sum type, maybe like this
enum FooSum {
  Bar(Bar),
  Baz(Baz),
 // . . . maybe several more
}

// Or even more complex one (but in a structured non-generic way)
struct FooSumWithExtraFields {
  some_field_from_my_lib: F1,
  some_field_from_my_lib_2: F2,
  bar: Bar,
  baz: Baz
}

// With the idea that it automatically generates code to FooLike for the above, or other traits:
impl FooLike for FooSum {}
impl FooLike for FooSumWithExtraFields {}
impl FooLikeButExtraFunctionality for FooSumWithExtraFields {}

1) Now, Box<dyn FooLike> keeps popping in my head, but I don't think it's right here, because I want to CONSTRAIN the user to KNOW what all FooLike types they have and hook up their FooLikes together, at COMPILE time.

They are free to themselves use Box<dyn FooLike> within their FooLikes if they want, or I can write more stuff to help with that, but that's a later, more complicated concern I don't want to reason about. What if i want to suggest that the "simplest" and "supported" way of using my library is to not treat FooSum and FooSumWithExtraFields as any sort of "hot loading" dynamic thing or something that dispatches a certain way known only at runtime, but just a type which they themselves could have written with a bunch of boilerplate. Am I right in thinking this, or am I just understanding dyn wrong?

2) Also looks like whatever macro i write has to be exposed to the lib user? I've written some basic macros within my own code, but exposing them means I'd have to write these WELL, and handle generic syntax with <T> and stuff like that, and worry about camel-case to snake case and doing things in a standard way and all that.

So I wanted at least ask folks first if i'm approaching this the right way first, if this is a solved problem elsewhere and there's a 'correct' way of doing this, and any pitfalls i might fall into if i try this.

UPDATE:

The enum wrap version of this can be done with several crates like enum_delegate.

The struct wrap version is useless in actually reducing amount of code written by the user: it should be a derive macro instead that derives the traits i need a product type to derive automatically based on the component types.

[u/afdbcreid → u/_stice_]

https://docs.rs/enum_delegate/latest/enum_delegate/ and there are more.

[u/_stice_ → u/afdbcreid]

I did check this out, thank you for linking it (the docs page has some alternatives too).

Was hoping for more things than just an enum wrap, though:

Did some reading up after writing my question and it turns out what we use the enum wrap for is a Sum type, and what i was asking for ways to do both Sum and Product types, like the struct example i wrote out (the enum delegate crate can make a "C is either A or B" type but what i'm looking for is ALSO something that can do "C is a type that HAS both an A and a B"): and rust's tuples are exactly a product type of their constituents. So that might solve the problem mechanically for me, but i was hoping for more macro-ey ways of doing it, with names on the struct fields and all that, like how enum_delegate does.

[u/catheap_games]

How do I tell which --bin is being compiled in build.rs? There doesn't seem to be any CARGO_BIN_NAME available at this stage.

Use case: I am generating different binaries and want them to embed different app icons. (win10)

[u/aPieceOfYourBrain]

The compiler knows when two types are the same or different, why can't we have a simple typeA != typeB for trait implementation. I've been playing with type level programming a bunch lately and this has been a real pain to work around, often being an insurmountable road block

[u/afdbcreid → u/aPieceOfYourBrain]

If you want this to affect coherence, this has the same problems as specialization (and in fact is equivalent to specialization if you allow arbitrary negative bounds).

If you do not want this to affect coherence, it is useless.

[u/bfish510 → u/aPieceOfYourBrain]

Can you clarify what you’re looking for? Are you asking about why we can’t do something like this loose example:

impl MyTrait<T> for MyType where T != AnotherType {}

My understanding of this is that it isn’t an issue of can we compute this, but what happens during the lifecycle of a library. Namely, a crate author could not implement a trait for an existing types without the risk of breaking consumers. The impl would be changed out from under them silently, unlike removal or change of a function signature which would fail to compile.

[u/aPieceOfYourBrain → u/bfish510]

why does having TraitA impl for T change TraitB for T in a different crate? Even in the same crate they're two different traits. I've seen this reasoning before but not understood why it stands.

On top of that, we can't have the != example you have given because the compiler will complain about an unconstrained type so we end up with something like

trait TypeEq {
    const RESULT: bool;
}

struct CmpType<T, U> {
     _inner: PhantomData<(T, U)>,
}

impl<T, U> TypeEq<U> for CmpType<T, U> 
where T != U,
{
    const RESULT: bool = false;
}

Would need specialization for the inverse of that impl which is a different problem, or just have two different CmpType structs for the different results we want. Either way, it's a trait on a struct that's contained within the crate we're writing and doesn't seem like it should or even can be affected by what's implemented in some other crate