Introduce a required #[borsh(use_discriminant = true|false)] enum attribute when discriminants are specified

[frol]

Context:

• chore: release #146 (comment)
• feat!: ser/de enum discriminant #138 (comment)

Before #138 (#137), borsh did not respect explicit enum discriminant values:

#[derive(BorshSerialize)]
enum MyEnum {
    A = 20,
}

assert_eq!(MyEnum::A as u8, 20);
assert_eq!(MyEnum::A.try_to_vec().unwrap(), vec![20]);

In #138, the default behavior changed and while it was marked as a breaking change by releasing 0.11.0 version, it was flagged that it may silently break someone's code, which is totally valid concern, thus, we decided to use a required #[borsh(use_discriminant = true|false)] enum attribute to resolve ambiguity, so after 0.11.1 release, the expected behavior would be that the following code will raise a compilation error:

#[derive(BorshSerialize)]
enum MyEnum {
    A = 20,
}

This will generate the code equivalent to the borsh before 0.11.0:

#[derive(BorshSerialize)]
#[borsh(use_discriminant = false)]
enum MyEnum {
    A = 20,
}

This will generate the code equivalent to the implementation in #138:

#[derive(BorshSerialize)]
#[borsh(use_discriminant = true)]
enum MyEnum {
    A = 20,
}

In the future, we will default to true and make this attribute optional, and eventually deprecate it.

[frol]

@iho I suggest you take this one next.

cc @mina86

[mina86]

One thing worth noting here is that to make it as painless as possible for users, ideally code would detect if enum has discriminants specified. So #[derive(BorshSerialize)] enum Foo { A, B } would compile but #[derive(BorshSerialize)] enum Foo { A = 10, B } wouldn’t.

By the way, another use case for the annotation is enum Foo { A = 256 } which cannot be serialised when discriminants are used.

[iho]

@mina86 I tried to do as you suggested by detecting explicit discriminate and emitting compiler errors. #148

[dj8yfo]

closed by #183