assumeSafeAppend and purity

[Timon Gehr]

On 02/07/2012 03:48 AM, Steven Schveighoffer wrote:
> On Mon, 06 Feb 2012 21:32:05 -0500, Vladimir Panteleev
> <vladimir at thecybershadow.net> wrote:
>
>> On Tuesday, 7 February 2012 at 01:47:12 UTC, Jonathan M Davis wrote:
>>> 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?
>>
>> If precedent means anything, assumeUnique is pure.
>
> I think there is a difference -- assumeSafeAppend can make invalid data
> that you did not pass to the pure function.
>
> I'm still not sure if it's pure's job to protect data that you can get
> to via pointer arithmetic, but I think the two cases are different.
>
> -Steve

I think both cases are kinda equivalent, but you are right: pure does 
not protect from undefined behaviour nor is it supposed to guarantee 
memory safety.