-
Notifications
You must be signed in to change notification settings - Fork 680
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Add default nonce to frame_system::AccountInfo
#4159
Conversation
Signed-off-by: georgepisaltu <[email protected]>
@georgepisaltu I think #4034 is a better way to do this then. The one you are exploring was already done here: #1557 |
Signed-off-by: georgepisaltu <[email protected]>
The CI pipeline was cancelled due to failure one of the required jobs. |
I now read all of the threads. I just want to provide a working alternative to #4034, which I hope will be simpler. I'd like to avoid the boilerplate code introduced in that newtype solution if possible. I lightly reviewed #4034 and even if we decide to go with that approach, I'd like to trim as much of that boilerplate as possible. |
Signed-off-by: georgepisaltu <[email protected]>
Thanks, but I am not sure if your PR here is different from #1557 ? Also, could you point me to the boilerplate code that you are referring to? The intent of introducing a new type was to avoid a breaking change if possible. |
Main difference is that the default is a type on
I understand. The problem with the newtype is stated here, with a reasonable expectation here. The point of it was that we could somehow make it passthrough, so we get the most functionality with the least amount of code. The other approach has a new nonce type, I'm not saying all of this because I think there's something inherently wrong with that PR or the code there, I just want to provide an alternative to that. My reasoning is that, while we're trying to avoid a breaking change, an extra type in This is just my opinion and this PR is just a draft. If people want to merge #4034 I have no problem with that. |
I understand your concerns, but this type would essentially provided as an additional primitive that could be used directly. So, the runtime dev doesn't need to bother about these complexities at all.
Thanks! My intent was not to persuade you to not explore an alternate solution but avoid an implementation if something similar was already tried. But yes, please continue if you think this is better. |
Closing this in favor of #4034 |
No description provided.