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
