refactor: move types to zip format folder

[Its-Just-Nans]

No description provided.

[amazon-q-developer]

This refactoring successfully reorganizes AES/encryption-related types and the System enum into dedicated modules under src/format/. The changes are clean with no logic modifications - purely structural improvements for better code organization. All imports have been updated correctly throughout the codebase. No issues found that would block merge.

---

You can now have the agent implement changes and create commits directly on your pull request's source branch. Simply comment with /q followed by your request in natural language to ask the agent to make changes.

[gemini-code-assist]

Code Review

This pull request refactors the ZIP format specifications by moving AES and flag-related enums into a new format module and updating serialization logic for extra fields to use the Write trait directly. Key changes include the removal of Pod implementations for encryption structures and the addition of a new test case for AES version thresholds. Review feedback points out a missing import for size_of that would cause a compilation error and recommends using constants in tests to improve maintainability.

[Pr0methean]

Generally looks good, but we may as well do some refactors for the code that's moving into format/ since we need to cut a major release anyway.

[Pr0methean]

This method seems unnecessary. Can't it be either inlined or replaced with the From<AesVendorVersion> for u16 impl below?

[Its-Just-Nans]

I am now using as_u16() inside the From

[Pr0methean]

Why not just use as u16 inside the From and wherever else it's currently used, so AesVendorVersion can have one less method?

done

[Pr0methean]

Why not just use as u16 inside the From and wherever else it's currently used, so AesVendorVersion can have one less method?

[Its-Just-Nans]

I find it easier to have one method for all conversion to u16 In case we change how we do the conversion or for readability

…

On Sat, May 9, 2026, 09:26 Chris Hennick ***@***.***> wrote: ***@***.**** requested changes on this pull request. ------------------------------ In src/format/aes.rs <#827 (comment)>: > + pub const fn as_u16(self) -> u16 { + self as u16 + } Why not just use as u16 inside the From and wherever else it's currently used, and then not need this method? — Reply to this email directly, view it on GitHub <#827 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANP36K2JEO4MWGV4ZXDTQU34Z3MTDAVCNFSM6AAAAACYU2ASYWVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DENJXGI2DGOJZG4> . You are receiving this because you were assigned.Message ID: ***@***.***>

[Pr0methean]

I find it easier to have one method for all conversion to u16 In case we change how we do the conversion or for readability

In what circumstances would it ever possibly change? And in what sense is x.as_u16() less readable than x as u16? (Functional pipelines can already just use u16::from instead of a closure.)

[Its-Just-Nans]

I find it easier to have one method for all conversion to u16 In case we change how we do the conversion or for readability

In what circumstances would it ever possibly change? And in what sense is x.as_u16() less readable than x as u16? (Functional pipelines can already just use u16::from instead of a closure.)

I think there are no real argument, but some of mine

• I find that as_u16() is more readable
• I find that as_u16() is more explicit since it means we don't cast or anything
• If there are more type of VendorVersion that need more complex u16 representation, a specific function as_u16() could be easily changed