Custom bound for parity-util-mem-derive

[NikVolf]

Imagine the struct:

struct Transaction<B> {
  hash: B::Hash,
}

#[parity_util_mem::MallocSizeOf] will fail miserably there, because it will add something like that:

impl<B> MallocSizeOf for Transaction<B> where B: MallocSizeOf { ... }

what instead would be cool is be able to declare this:

#[derive(parity_util_mem::MallocSizeOf)]
struct Transaction<B> {
  #[custom_ty_bound]
  hash: B::Hash,
}

which expands to:

impl MallocSizeOf for Transaction<B> where B::Hash: MallocSizeOf { .. }

(so that concrete type used in structure got bounded, not generic argument)

if any #[custom_ty_bound] declared in the structure, default ones (B: MallocSizeOf) should not be added

[dvdplm]

Not sure I follow, what does the derived impl look like with #[custom_ty_bound] in your example?

[ordian]

You mean something like #255?

[NikVolf]

Not sure I follow, what does the derived impl look like with #[custom_ty_bound] in your example?

Yep sorry, forgot to expand. Obviously, actual type in structure gets bounded, not generic argument. So:

impl<B> MallocSizeOf for Transaction<B> where B::Hash: MallocSizeOf { .. }

[NikVolf]

You mean something like #255?

Not really. It has nothing to do with actual calculations, just with where section bounds generation.

[ordian]

Maybe we can have something like this https://github.com/paritytech/parity-scale-codec/pull/40?

[NikVolf]

Maybe we can have something like this paritytech/parity-scale-codec#40?

Yes, seems like the right direction. I don't really see the point of making stupid bounds on all generic arguments.

For example, this thing:

#[derive(MallocSizeOf)]
struct Foo<B> {
  member: PhantomData<B>
}

could go just without any bounds on B, because MallocSizeOf is implemented for any PhantomData

[ordian]

I don't really see the point of making stupid bounds on all generic arguments.

This is a long-standing issue in rustc https://github.com/rust-lang/rust/issues/26925 that will hopefully be resolved with chalk, but it may take a while (as you can see the issue is 5 years old).