On Fri, 01 Apr 2011 06:38:56 -0400, Regan Heath <re...@netmail.co.nz>
wrote:
On Mon, 28 Mar 2011 17:54:29 +0100, bearophile
<bearophileh...@lycps.com> wrote:
Steven Schveighoffer:
So essentially, you are getting the same thing, but using [] is slower.
It seems I was right then, thank you and Kagamin for the answers.
This may be slightly OT but I just wanted to raise the point that
conceptually it's nice to be able to express (exists but is empty) and
(does not exist). Pointers/references have null as a (does not exist)
"value" and this is incredibly useful. Try doing the same thing with
'int' .. it requires you either use int* or pass an additional boolean
to indicate existence.. yuck.
I'd suggest if someone types '[]' they mean (exists but is empty) and if
they type 'null' they mean (does not exist) and they may be relying on
the .ptr value to differentiate these cases, which is useful. If you're
not interested in the difference, and you need performance, you simply
use 'null'. Everybody is happy. :)
The distinction is useful if you have something to reference (e.g. an
empty slice that points at the end of a pre-existing non-empty array).
But [] is a new array, no point in allocating memory just so the pointer
can be non-null. Can you come up with a use case to show why you'd want
such a thing?
Your plan would mean that [] is a memory allocation. I'd rather not have
the runtime do the lower performing thing unless there is a good reason.
As an alternative, you could use (cast(T *)null)[1..1] if you really
needed it (this also would be higher performing, BTW since the runtime
array literal function would not be called).
-Steve
