Considering the if (!initialized) pattern

[414owen]

A lot of operations are defined on "uninitialized" types. For example rand checks whether the underlying structure is initialized, and if not, it seeds it, and sets the initialized flag.

This seems like unnecessary overhead and complexity to me. Firstly, the check itself. While it'll (probably) be branch-predicted correctly from the third use onwards, and might only add minimal overhead in microbenchmarks, branch predictor saturation exists, and in larger codebases, this will manifest as latency that a user won't track down.

Some types don't have an existing field which indicates whether they are initialized, meaning we have to store extra state, as is the case with the initialized boolean.

---

Proposed solution:

Allow the user to specify that the initialization of a type is mandatory, via an attribute on the type declaration.
This would (probably) mean having initializers that return a new value (eg. new :: uint -> HashMap), rather than initializing an uninitialized value.
Optionally, allow users to specify a default initializer, which would be used instead of the default zero-initialization.
Migrate the stdlib to this pattern, and remove lots of checks for !initialized.

[lerno]

In the case of "rand" it's special, since that is a convenience method for getting random numbers from a common thread local random, it's not an optimized function. For that you should instead use a custom random generator.

[lerno]

Using (A) was my intuition, but I am questioning it. It's the hardest to get right, and there are other issues with it as well.

[lerno]

There is also the enhanced ABI stability of using B, C or D.

[414owen]

There is also the enhanced ABI stability of using B, C or D.

Won't a change in the structure result in ABI breakage whether the outer layer is on the heap or not? Where does the extra stability come from?

[lerno]

If the type is opaque, then all manipulation of the data occurs through functions, which are provided by the library itself.

Imagine you compile for 1.0 and dynamically link with it. You create with new do an append which calls the append function. This calls 1.0 new, giving you a pointer to a 1.0 object and then invokes 1.0 append.

Now this program is run with 1.1. This means it now calls 1.1 new, will get the 1.1 data, and 1.1 append.

[414owen]

Okay I see what you mean. I personally wouldn't care much about being able to use different dynamically linked versions of the stdlib without recompiling my code, so I wouldn't pick that over more performance. I can see the appeal though.