EricWF added a comment.
If we choose to special case this I think we *need* to do it with a new
specialization of `default_delete<T[N]>`, not using the primary template.
The primary templates defines `default_delete<T[N]>::pointer` as `T*[N]`, which
`T*` will not convert to. That means this patch still rejects things like
`default_delete<int[5]>{}(new int[5])` and `unique_ptr<int[5]>(new int[5])`
which should obviously work if we support this.
The new specialization should instead act in the same way as
`default_delete<T[]>` and define `pointer` to be `T*`. Only after doing this
do we end up with something useful.
However, We are *NOT* fixing previously buggy code. This is a pure extension.
Nobody is running into bugs caused by `default_delete<T[N]>` calling the wrong
delete method on *non-null* pointers, because only null literals convert to
the pointer type`T*[N]`. Non-null pointers returned from `new` or `malloc`
require a `reinterpret_cast<Delete::pointer>(p)` before they can be passed to
the deleter. If they don't do this they will get a compile error.
IMHO instead of trying to make this work, we should diagnose it as early as
possible. Any code that uses default_delete<T[N]> is going to run into a
compile error pretty quickly so, we might as well make it a pretty one.
Anyway thats my 2 cents. I'll be quite now.
http://reviews.llvm.org/D21320
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
