On Monday, 19 May 2014 at 18:51:31 UTC, Dicebot wrote:
If it still resorts to GC in this case, utility of such addition sounds questionable.
It's not really an "addition" as much as it is a "necessary building block to make higher order GC functions work": For example, "dup" was recently made a druntime library implemented function, and as such, required that function to allocate, before building data onto it.
Huh, will it also make possible to call `realloc` if capacity is exceeded?
AFAIK, using the "GC.realloc" (or "GC.extent") function on it directly would not work. This may or may not be an issue with how "GC.realloc" is designed. The reason for this is because this functions are actually "extremelly" low level, and simply request GC memory, without knowing or caring about the APPENDABLE data. So while the calls could succeed, the result would not be useable.
Currently, you could just use "reserve" or simply allocate again, to achieve almost the desired result. reserve+assumeSafeAppend would basically be a "void-extend" (as opposed to "size", which would be an "initialized extend").
At the end of the day though, it can all be done, but it's really about what you want to expose in "object.d".
