Skip to content
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

Private Struct Fields for Blockchain Types #5613

Merged
merged 17 commits into from
Feb 26, 2024

Conversation

bitzoic
Copy link
Member

@bitzoic bitzoic commented Feb 15, 2024

Description

Updates the following blockchain types to have private struct variables:

  • Address
  • ContractId
  • AssetId

Note: This PR merges into a staging branch

Checklist

  • I have linked to any relevant issues.
  • I have commented my code, particularly in hard-to-understand areas.
  • I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • I have added tests that prove my fix is effective or that my feature works.
  • I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
  • I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
  • I have requested a review from the relevant team or maintainers.

@bitzoic bitzoic added lib: std Standard library breaking May cause existing user code to break. Requires a minor or major release. labels Feb 15, 2024
@bitzoic bitzoic requested a review from a team February 15, 2024 05:21
@bitzoic bitzoic self-assigned this Feb 15, 2024
@bitzoic bitzoic changed the title Encapsulation of Blockchain Types Private Struct Fields for Blockchain Types Feb 15, 2024
Copy link
Member

@K1-R1 K1-R1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look good, but with these fields now private how would these types be instantiated as constants or configureable constants?
Currently we are able to do:

configurable {
    SIGNER: Address = Address {
        value: ZERO_B256,
    },
}

Initialising with Address::from(ZERO_B256) would cause the error:

^^^^^^^^^^^^^^^^ Could not evaluate initializer to a const declaration.

@K1-R1 K1-R1 requested a review from a team February 15, 2024 19:04
@bitzoic
Copy link
Member Author

bitzoic commented Feb 16, 2024

Changes look good, but with these fields now private how would these types be instantiated as constants or configureable constants? Currently we are able to do:

configurable {
    SIGNER: Address = Address {
        value: ZERO_B256,
    },
}

Initialising with Address::from(ZERO_B256) would cause the error:

^^^^^^^^^^^^^^^^ Could not evaluate initializer to a const declaration.

What version of forc are you using to test this? I've added tests to add Address and ContractId using From implementation in configurable in this commit.

@K1-R1
Copy link
Member

K1-R1 commented Feb 16, 2024

What version of forc are you using to test this? I've added tests to add Address and ContractId using From implementation in configurable in this commit.

I tried it with forc = "0.50.0". If it's working on this PR though it's a non-issue.

@bitzoic bitzoic requested a review from K1-R1 February 21, 2024 04:13
@bitzoic bitzoic merged commit cfc8e19 into bitzoic-encapsulation Feb 26, 2024
38 checks passed
@bitzoic bitzoic deleted the bitzoic-encapsulation-blockchain-types branch February 26, 2024 05:05
@bitzoic bitzoic mentioned this pull request Feb 26, 2024
7 tasks
IGI-111 added a commit that referenced this pull request Mar 3, 2024
## Description

Merges the staging branch into master from the following PRs:

#5640
#5630
#5621
#5613

## Checklist

- [x] I have linked to any relevant issues.
- [x] I have commented my code, particularly in hard-to-understand
areas.
- [x] I have updated the documentation where relevant (API docs, the
reference, and the Sway book).
- [x] I have added tests that prove my fix is effective or that my
feature works.
- [x] I have added (or requested a maintainer to add) the necessary
`Breaking*` or `New Feature` labels where relevant.
- [x] I have done my best to ensure that my PR adheres to [the Fuel Labs
Code Review
Standards](https://github.com/FuelLabs/rfcs/blob/master/text/code-standards/external-contributors.md).
- [x] I have requested a review from the relevant team or maintainers.

---------

Co-authored-by: IGI-111 <[email protected]>
Co-authored-by: Sophie Dankel <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking May cause existing user code to break. Requires a minor or major release. lib: std Standard library
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants