Reorganizing sway-std-lib

[Braqzen]

Description

Type: Improvement

What does your feature accomplish?

It makes it easier to navigate the standard library depending on the context. Furthermore, it makes it easier to scale the size of the library.

How does your feature accomplishes your goal?

It accomplishes this by looking at the context of what each file achieves and groups them together under directories e.g. ecr.sw and hash.sw can be grouped under hashing or cryptography.

Draft implementation

1. We have a chain.sw which only has a dep decleration inside. We also have a chain directory. This should be reorganized.
2. We have context.sw and also a context directory, this too should be fixed.
3. assert.sw and require.sw should probably be grouped together if not placed in the same file
4. option.sw and result.sw should also be together, perhaps with logging.sw?
5. ecr.sw and hash.sw should be together, keep in mind that we have a vm directory which is specifically for EVM equivalent ecr
6. intrinsics.sw, storage.sw, block.sw, context.sw and chain.sw could be together?
7. address.sw, contract_id.sw, b512.sw and u128.sw can be together?

cc @nfurfaro @adlerjohn @sezna @otrho

[adlerjohn]

Things that are mirrors of the Rust standard library should be kept as they are in Rust. E.g. Result is in std::result (https://doc.rust-lang.org/std/result/) and Option is in std::option (https://doc.rust-lang.org/std/option/).

For our own types and functions, it's definitely the case that things could be reorganized. E.g. a crypto module for hashing and signature stuff. Note that this will require extreme care: the suggestion "option.sw and result.sw should also be together, perhaps with logging.sw" is exactly something we don't want to do. The former two are mirrors of Rust stdlib types, while logging is something completely orthogonal and has to do with the blockchain. They have no semantic relationship.

Designing a proper API is non-trivial, and we have to take extreme care when designing the stdlib API to make it good. In the interim, avoiding grouping and having a flat structure at least doesn't impose any implicit semantics on groups of functions/types.

[nfurfaro]

I could flatten the lib structure as an initial step but would prefer to minimize breaking changes around import paths. Better would be to:

• hash out a new structure we can use going forward
• implement the breaking changes once
• use care moving forward to get additions to the API right the first time, avoiding breaking changes entirely.

I could draft a new lib structure (maybe in a google doc?) and we can discuss/modify it till we're happy.

[nfurfaro]

Posting this google doc link here for discussion: https://docs.google.com/document/d/12l3Mpd4eKuaXwMnU-M6bwvny6TWIU-Kv_2fdtH-qx04/edit#heading=h.a4ihrw3m5omr