Phobos addition formal review: std.experimental.allocator

[Andrei Alexandrescu via Digitalmars-d]

On 7/14/15 7:35 AM, Jacob Carlborg wrote:
> On 2015-07-13 20:52, Andrei Alexandrescu wrote:
>
>> That design would have been possible, e.g. have deallocate return false,
>> owns return Ternary.unknown, expand return false, alignedAllocate return
>> null etc.
>
> Perhaps it's a simplified view, but for all examples in the talk it
> seems it would work without changing the API. The branch which was
> executed for "does not support this operation" was the same for "this
> operation failed". Example:
>
> static if (hasMember!("deallocate"))
>      deallocate();
>
> There was no "else", no action when "deallocate" was not supported. Or:
>
> static if (hasMember!("reallocate"))
>      return reallocate();
> else
>      return false;

I explained matters at length in the post you're replying to, and from 
what I can tell this reply is a reiteration of your same point. I don't 
know what to add - you may want to pay some more mind to that post.

> Of course I haven't look through the whole source code.

One easy way to take a look at things is to clone the branch and then:

git grep --context=5 hasMember

or however many lines you need.

> Yeah, my suggestion assumes the compiler can optimize away all these
> dummy functions.

There were two other considerations.


Andrei