allow for u8 to be used as hold/freeze reason

[kianenigma]

..without needing to provide your own newtype around it.

This will allow type Reason = u8 to be used as FreezeReason and HoldReason, which I think is a nice simplification if one doens't want to deal with the complications.

At the same time, it is a bit of an anti-pattern.

Putting it out there to check people's vibes.

[bkchr]

We have RuntimeHoldReason and RuntimeFreezeReason, why do people need to put there u8?

[kianenigma]

We have RuntimeHoldReason and RuntimeFreezeReason, why do people need to put there u8?

Simpler code for starter templates and so on. Imagine how many fewer mental barriers you have to "get your first hold working", if you provide a template to students that works with a constrained Reason = u8, rather than needing to pull into RuntimeHoldReason, know about the relation between the two, and how to convert from one to other.

I am working on one such template here https://github.com/kianenigma/flite. WIP.

Basically, this tricks prevents one from needing to understand this whole page.

https://paritytech.github.io/polkadot-sdk/master/polkadot_sdk_docs/reference_docs/frame_runtime_types/index.html

None of this is an issue for us and those who are already familiar ofc.

[bkchr]

Imagine how many fewer mental barriers you have to "get your first hold working", if you provide a template to students that works with a constrained Reason = u8, rather than needing to pull into RuntimeHoldReason, know about the relation between the two, and how to convert from one to other.

Not sure how providing a random u8 is easier to understand. You are injecting the other runtime types as well using the derive_impl macro, not sure why you can not do the same for these types?

polkadot-sdk/substrate/frame/nomination-pools/src/lib.rs

Line 3464 in d8c2944

T::Currency::balance_frozen(&FreezeReason::PoolMinBalance.into(), reward_acc);

having an enum for hold/freeze is IMO much cleaner. It is like you try to campaign for using C style here, which would be an u8. Here you just have a 0 as reason. I would be much more confused on what this 0 means and what I should use there in a real application. Or should I use 0 everywhere? You will in the end also write more docs instead of giving the thing a fixed name WHATEVER_HOLD and it explains the user right away what it is about.

[bkchr]

But if you really think that a plain 0 is better there, I will approve this.