Closed thirtytwobits closed 3 years ago
we ship a simple static allocator for use with variable-length arrays and make it the default?
Yeah. I think that makes sense.
Also, one thing I forgot to mention: can we please support at least a basic iterator API (pointer-based) for the variable array type? Otherwise, the class would be much less useful when interfacing with 3rd-party code.
Also, one thing I forgot to mention: can we please support at least a basic iterator API (pointer-based) for the variable array type? Otherwise, the class would be much less useful when interfacing with 3rd-party code.
I'd like to release this initially with the most minimal support needed for ser/des. Let's then analyze usage and expand as real use cases present themselves. I really don't want to provide a generalized container library from Nunavut. That doesn't seem like its competency.
Also note that the CI will remain broken until we agree on the content of the PR as I'm restructuring the CI interface to better support parallelization going forward.
@thirtytwobits are you planning to further advance this or do you want it merged as-is?
@thirtytwobits are you planning to further advance this or do you want it merged as-is?
I have more work to do to respond to all your comments.
@pavel-kirienko , let me know if this is okay to merge as-is (i.e. the c++ work isn't done but we need to get all this change in) and I'll fix up the CI
This is a checkpoint merge to put a firebreak in a growing change-set. Most all of these changes are behind the --experimental-language flag so there's little risk. There are a couple of fixes in the core python library that should not break anybody we know of.
Highlights: