Skip to content

Conversation

@igamigo
Copy link
Collaborator

@igamigo igamigo commented Jan 6, 2026

Closes #1860
Also simplifies/removes some code

@igamigo igamigo force-pushed the igamigo-init-refactor branch 2 times, most recently from 0fe55a6 to 537805b Compare January 7, 2026 22:10
@igamigo igamigo force-pushed the igamigo-init-refactor branch from 537805b to 98c040f Compare January 7, 2026 22:14
@igamigo igamigo marked this pull request as ready for review January 7, 2026 22:14
@igamigo igamigo changed the title feat: Extend InitStorageData and allow passing native structs feat: extend InitStorageData and allow passing native structs Jan 7, 2026
@bobbinth bobbinth requested review from bobbinth and mmagician and removed request for PhilippGackstatter January 8, 2026 16:20
Copy link
Contributor

@mmagician mmagician left a comment

Choose a reason for hiding this comment

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

Just to make sure my understanding is correct, the title "allow passing native structs" refers to allowing native Miden value types (Word, Felt) to be passed directly into InitStorageData, instead of requiring parsed WordValues? (basically 1. from @partylikeits1983's proposal)

I haven't done a full review of the fine details, but on a high level there might be a chance of simplifying the structs a bit, see my comment below

Copy link
Contributor

@mmagician mmagician left a comment

Choose a reason for hiding this comment

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

I'm wondering when exactly do we utilize InitStorageData::new() in practice?
I imagine that typically the init storage data will be provided via a TOML file, i.e. using InitStorageData::from_toml constructor.

cc @partylikeits1983 as this PR addresses #1860

Other than this question, the changes LGTM ✅
I added a few unit tests to cover the missing error variants.

Comment on lines 198 to 207
/// Inserts a single map entry.
///
/// See [`Self::insert_value`] for examples of supported types for `key` and `value`.
pub fn insert_map_entry(
&mut self,
slot_name: StorageSlotName,
key: impl Into<WordValue>,
value: impl Into<WordValue>,
) {
self.map_entries.entry(slot_name).or_default().push((key.into(), value.into()));
Copy link
Contributor

Choose a reason for hiding this comment

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

should this return a Result instead, and reject if duplicates are inserted?

@mmagician
Copy link
Contributor

Regarding my previous question, I was just genuinely wondering about the different constructors. Because by removing the new() constructor, the value of converting from native structs becomes much less important AFAICS?

@igamigo
Copy link
Collaborator Author

igamigo commented Jan 13, 2026

Regarding my previous question, I was just genuinely wondering about the different constructors. Because by removing the new() constructor, the value of converting from native structs becomes much less important AFAICS?

I had thought of this as well. Before this PR, the main advantage of having something like InitStorageData was that it provided a way to pick up defaults from TOML and then validate those values against a schema. With #1860, the idea is that it also becomes usable with "native"/domain structs. This lends itself to one of two ways of using the struct:

  • InitStorageData::from_toml() -> maybe mutate it? -> use it to instantiate a component.
  • InitStorageData::default() -> insert enough values -> instantiate a component.

So I agree with the fact that it maybe decreases the value of converting from native structs, but also the mutators added in this PR are hopefully ergonomic enough that it's not a nuisance to do this pattern instead of preparing a list of values to pass to InitStorageData::new().

Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

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

Looks good! Thank you! I left some comments inline - most of them can be addressed in a follow-up.

Comment on lines +133 to +137
pub fn insert_value(
&mut self,
name: StorageValueName,
value: impl Into<WordValue>,
) -> Result<(), InitStorageDataError> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe not for this PR, but would it make sense to also define the type for the name parameter as impl TryInto<StorageValueName>? This way, it may be possible to write something like:

data.insert_value("foo::bar.baz", Felt::from(42_u32));

Also, maybe we should implement more conversions for WordValue - e.g., From<u32>, From<[u32; 4]> etc. Or if there is a way somehow to do a blanket implementation so that anything that can be converted into word can be converted into WordValue, that would be even better - but not sure that's possible.

Comment on lines +151 to +156
pub fn insert_map_entry(
&mut self,
slot_name: StorageSlotName,
key: impl Into<WordValue>,
value: impl Into<WordValue>,
) -> Result<(), InitStorageDataError> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment re potentially making slot_name be impl TryInto<StorageSlotName>.

Comment on lines +178 to +182
pub fn set_map_values(
&mut self,
slot_name: StorageSlotName,
entries: Vec<(WordValue, WordValue)>,
) -> Result<(), InitStorageDataError> {
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment re slot_name as above.

Comment on lines 971 to 972
// TESTS
// ================================================================================================
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe not for this PR, but I'd move the tests into a separate file as this file is already quite large.

Or another option could be to split the file up into logical components (e.g., map slot schema, value slot schema) under src/account/component/storage/schema directory.

Copy link
Contributor

@bobbinth bobbinth left a comment

Choose a reason for hiding this comment

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

Looks good! Thank you! I'll merge this as soon as CI passes. Could you create an issue with the remaining follow-ups?

@bobbinth bobbinth merged commit 60baeda into next Jan 16, 2026
17 checks passed
@bobbinth bobbinth deleted the igamigo-init-refactor branch January 16, 2026 17:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Improve InitStorageData structure for better usability

5 participants