assumeSafeAppend and purity

[Jonathan M Davis]

At present, assumeSafeAppend isn't pure - nor is capacity or reserve. AFAIK, 
none of them access any global variables aside from GC-related stuff (and new 
is already allowed in pure functions). All it would take to make them pure is 
to mark the declarations for the C functions that they call pure (and those 
functions aren't part of the public API) and then mark them as pure. Is there 
any reason why this would be a _bad_ idea?

Appender runs into similar difficulties. Would it make sense to just mark the 
various memory-related functions in core.memory as pure (or at least some 
subset of them)? The fact that they aren't in spite of the fact that they 
involve memory like new does really makes it hard to both use pure and 
optimize code in a number of cases - especially when dealing with arrays. We 
might also want to just mark malloc as pure for the same reason.

What are the downsides to doing this? It probably wouldn't be a good idea to 
mark functions like free pure, but the ones that involve allocating or 
reallocating memory seem like good candidates for it.

- Jonathan M Davis