-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
[move][adapter] Static init rules #1532
Conversation
tnowacki
commented
Apr 21, 2022
- Made init rules static
- The existence of the function is optional
- The function must be named 'init'
- The function must be private
- The function can have a single parameter, &mut TxContext
- Alternatively, the function can have zero parameters
- Made init rules static - The existence of the function is optional - The function must be named 'init' - The function must be private - The function can have a single parameter, &mut TxContext - Alternatively, the function can have zero parameters
See #1323 |
Cool! Thank you for taking on this!
|
The intention was to emphasize the fact that this is not a "regular" (callable) function. |
Well, private function only constrains other non-friend modules from calling it. You can still call it from within and friend modules. So I think a verifier that forbids calling it is needed anyway. If so, we can make it public |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A general comment. At least part of the reason that this was not implemented in the verifier is that when talking to @sblackshear, we were not sure if init
should be treated as (practically) a keyword for function naming (a function called init
MUST be a module initializer). On the one hand, this makes things more explicit, and on the other - it is somewhat restrictive from programmer's perspective. I am totally cool with the stricter solution, though.
I feel fine basically keywordifying it for Sui move.
It is annoying... but you could always do something like
More on this part, this this rule already in place? |
No there isn't. But I think we should have it? |
I'll land this, with a followup for a "don't call init" init rule |
* refactor * clean up * refactor rebase * rebase * rebase * add how-to * format * lint * don't pop key, copy it * Add a safe client function that augments the follower API with downloading the transactions information (#1446) Co-authored-by: George Danezis <[email protected]> * Removing dev-addresses from Move.toml (#1536) There is no undefined address in the [addresses] section (e.g. AddressToBeFilledIn = "_") so having a [dev-addresses] section is not necessary. * [move][adapter] Static init rules (#1532) - Made init rules static - The existence of the function is optional - The function must be named 'init' - The function must be private - The function can have a single parameter, &mut TxContext - Alternatively, the function can have zero parameters * adds a counter example (#1539) * sui: reorganize binaries * wallet: log git revision on start * Refactor Build index by common user workflow (#1530) * Refactor Build index by common user workflow * Update index.md Fix paths missing Markdown file extension * Update index.md (#1545) Removing tutorial series until ready * Update index.md Remove version from API link Capitalize REST * comments and add unwind logic for process * fix: remove one unneeded instance of key_pair.copy() * fix: remove three unneeded instances of key_pair.copy() * fix: remove one unneeded instance of key_pair.copy() * refactor rebase * rebase * refactor * rebase * rebase * add how-to * lint * don't pop key, copy it * rebase * Update index.md Remove version from API link Capitalize REST * rebase Co-authored-by: Lu Zhang <[email protected]> Co-authored-by: George Danezis <[email protected]> Co-authored-by: George Danezis <[email protected]> Co-authored-by: jaredcosulich <[email protected]> Co-authored-by: Todd Nowacki <[email protected]> Co-authored-by: Damir S <[email protected]> Co-authored-by: Brandon Williams <[email protected]> Co-authored-by: Clay-Mysten <[email protected]> Co-authored-by: François Garillot <[email protected]>