Why are derives inside of the nutype macro?

[zexa]

The following snippet came as a surprise to me. Why are derives inside of the nutype macro instead of using their own annotations?

That is, why is it like this?

#[nutype(
    sanitize(trim, lowercase),
    validate(not_empty, len_char_max = 20),
    derive(Debug, PartialEq, Clone),
)]
struct NuType(String);

Instead of like this:

#[nutype(
    sanitize(trim, lowercase),
    validate(not_empty, len_char_max = 20),
)]
#[derive(Debug, PartialEq, Clone)]
struct NuType(String);

I'm assuming there's a good reason, and I'm curious.

[greyblake]

@zexa Hi, thanks for asking, the question is very valid!

In version 0.1.0 in fact deriving was like you suggested: https://github.com/greyblake/nutype/tree/v0.1.1?tab=readme-ov-file#a-few-more-examples (yeap, it even supported *).

Nutype overtakes full control over the traits than can be derived. To keep it simple, there is just a whitelist of traits that are allowed to be derived. The reason for this is to prevent deriving a traits that can mutate the inner state and violate the constraint by bypassing the validation (e.g. DerefMut would do that).

There are 2 reasons, why I've decided to move derive() within nutype macro.

1. To make it explicit that the derive is fully controled by the nutype. Otherwise users may feel like they're having regular deriving experience, but it's not. And users could be very confused when things don't work exactly the way they may exect.

2. The order was important. If you use #[nutype(..)] before #[derive(..)] (like in your example), things would work. If you change the order, things would not work and would result into a cryptic message that is hard to understand unless you know well what #[nutype] generates under the hood.