LIB FEATURE TODO LIST

[alex-s168]

this issue contains all stdlib tasks that are not in stdlib feature tracking

• MaybeUninit<t>; only useful after allow function parameters to "poison" the input value #1266
• SerialVal <=> S expression; depends on stdlib collection improvements #1250
• CBOR (de-) serialization
• standard semver parser
• good cli argument parser
• date and time related functions, independent from libc (reference)
• more path manipulation functions
• way more unit tests.
• endianess conversion

currently unimportant:

• BigInteger and BigDecimal
• JSON parser and writer, that can change values without changing the formatting
• INI parser and writer, that can change values without changing the formatting
• HOCON parser and writer for SerialVal, that can change values without changing the formatting
• shell argument escape function
• cli progress "bar" with tree-like structure, like in Zig's stdlib
• generic compiler error message printer, similar to ariadne
• unicode strings and conversion between utf8, utf16, and utf32
• UUID related stuff
• simple, fast, key-value store. useful for the build system and incremental compilation
• BSON (de-) serialization: binary json-like format that can be updated in-place
• JSONB (de-) serialization

When you want to tackle any of these tasks, please create a separate issue, and make sure to write unit tests.
Many of these should be moved into separate packages in the future.

[andrew-johnson-4]

• replace s.lsts with SerialVal introduced in https://github.com/andrew-johnson-4/lambda-mountain/pull/1283

I like S-expressions. They would be hard to replace in core and codegen.

The core "Fragment" data structure is logically a mapping of strings to S-Expressions. I consider this a core feature of the backend. This relation is also semantic for fully certified builds. I want to actually prove properties about those S-Expressions / Fragments.

[alex-s168]

• replace s.lsts with SerialVal introduced in unversal serialization #1283

I like S-expressions. They would be hard to replace in core and codegen.

The core "Fragment" data structure is logically a mapping of strings to S-Expressions. I consider this a core feature of the backend. This relation is also semantic for fully certified builds. I want to actually prove properties about those S-Expressions / Fragments.

I didn't think about it that way.
Removed the task