SNIP-12 Defining types

[gaetbout]

Definition of a type

[penovicp]

I would suggest adding two more rules to reduce potential ambiguity some more:

• Name can't be enclosed in whitespace characters
• Name can't contain the comma (,) character (this is since enum types use it as a delimiter)

[sgc-code]

I would suggest adding two more rules to reduce potential ambiguity some more:

• Name can't be enclosed in whitespace characters
• Name can't contain the comma (,) character (this is since enum types use it as a delimiter)

hi @penovicp, thanks for your feedback

• regarding enclosing in whitespace characters, i think the difficulty would be to define whitespace characters, there are many unicode characters that might fall into that definition. IMO this is similar trying to make sure users are not fooled with a cyrillic а instead of a regular a. We can't avoid this problem at the SNIP level so i'd accept that and keep the SNIP simple

• disallowing comma in the enum names is not strictly needed because the names are escaped to calculate the type hash, unless i'm missing something

[penovicp]

For the whitespace rule I would assume just using the word "whitespace" and relying on the \s RegEx could be sufficient. I would hope that it's mostly standardized between different programming languages. Admittedly, I haven't done a deep dive on the topic to know if there are any differences/edge cases for more obscure character sets.

For the enum rule, if the incoming type definition for the enum contains { "name": "Variant N", "type": "(u128,u128)" }, there is ambiguity if the variant is a u128 tuple or a u128,u128 type.

[sgc-code]

For the whitespace rule I would assume just using the word "whitespace" and relying on the \s RegEx could be sufficient. I would hope that it's mostly standardized between different programming languages. Admittedly, I haven't done a deep dive on the topic to know if there are any differences/edge cases for more obscure character sets.

For the enum rule, if the incoming type definition for the enum contains { "name": "Variant N", "type": "(u128,u128)" }, there is ambiguity if the variant is a u128 tuple or a u128,u128 type.

Regarding white space, we prefer to keep it as is, because we are not sure about that all regex work the same, and because that change won't actually make SNIP-12 safer

Regarding the enums, you are right, and we have updated this PR with that change.

I believe this PR is now ready to be merged so different SDKs can implement it

[github-actions[bot]]

There hasn't been any activity on this pull request recently, and in order to prioritize active work, it has been marked as stale. This PR will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[sgc-code]

@ArielElp can we merge this?

[gaetbout]

@ArielElp up 😅

[github-actions[bot]]

There hasn't been any activity on this pull request recently, and in order to prioritize active work, it has been marked as stale. This PR will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[gaetbout]

@ArielElp 🙏 ?

[github-actions[bot]]

There hasn't been any activity on this pull request recently, and in order to prioritize active work, it has been marked as stale. This PR will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[gaetbout]

le dot of activity

[github-actions[bot]]

There hasn't been any activity on this pull request recently, and in order to prioritize active work, it has been marked as stale. This PR will be closed and locked in 7 days if no further activity occurs. Thank you for your contributions!

[gaetbout]

Le ping to stay alive