On Fri, 01 Apr 2011 18:23:28 +0100, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Fri, 01 Apr 2011 11:52:47 -0400, Regan Heath <re...@netmail.co.nz>
wrote:
But, in D it seems I cannot do this. In D I would have to pass an
additional boolean parameter, or add another level of indirection i.e.
pass a string[]*. The same problem exists in C if I want to pass an
'int' or any primitive type, I have to pass it as int*, use a boolean,
or invent a 'special' value which means essentially
NULL/not-set/ignored.
assert("" !is null); // works on D. Try it.
Yes, but that's because this is a string literal. It's not useful where
you're getting your input from somewhere else.. like in the other 2 use
cases I mentioned.
However.. I've realised that in those cases, where you have an input array
you can slice, eg.
auto y = "a=123&b=&c=456"
auto z = y[8..8];
I do get an array 'z', with a non-null ptr. So, provided D doesn't lose
this information when I pass it around I am fine. The other use case may
be a little more problematic depending on the method used to read the
input from the keyboard, IIRC one of the methods returns null for a blank
line of input, which I would have to detect and 'fix' using emptyArray if
I wanted to pass it to something that cares about the distinction.
I'm not too bothered what syntax gets used, provided it was something
that you don't accidently use when you do not want it, and wasn't too
horrible to use as I don't see this as being a very uncommon occurance
(which would warrant/allow ugliness of syntax). "[]" >> seems logical,
as does "new T[]", both are not "null" so the programmer was obviously
trying to do something other than pass null.
It's one thing to want an array with a non-null pointer, but it's
another thing entirely to want an array with a non-null pointer which
points to a valid heap address.
I don't specifically want either of those things. I just want _some way_
to represent 'exists but is empty' and for it to be different to 'does not
exist'. Currently D's arrays cannot do that, yet a plain old pointer can.
In my opinion, [] means empty array. I don't care what the pointer is,
as long as the array is empty. The implementation can put whatever
value it wants for the pointer. If it wants to put null, that is fine.
null means I want a null pointer.
If I had it my way, all array literals would be immutable, and the
pointers would point to ROM (even empty ones). We should not be
constructing array literals at runtime. But my opinion is still that
you should not count on the pointer being anything because
it's not specified what it is.
Sure, I agree with all that, but I still want some way of representing
both states and detecting both states and the problem is that if the
language cannot do it at a fundamental level, and requires some weird hack
or reliance on string literals then when I use any 3rd party library, or
phobos itself it will tell me null and I will have to guess which state it
actually means and 'fix' it manually.
That seems to work, but it's hideous syntax for something that is not
that uncommon IMO.
My opinion is that it is uncommon, but it can be abstracted:
template emptyArray(T)
{
enum emptyArray = (cast(T*)0)[1..1];
}
rename as desired.
Not useful if you're getting your input from somewhere else, vs trying to
create a new empty array.
That said, if I were to want this I'd use the literal instead as it seems
safer, eg.
template emptyArray(T)
{
enum emptyArray = cast(T[])""[0..0];
}
This code seems to disagree with your results for case 5 (dmd 2.052):
auto x = cast(char[])""[0..0];
assert(x.ptr != null); // no failure
Nope, my case 5 had a 'dup' which you're missing. If I add a new case
returning a literal as you have there I get the same result as you. I was
intentionally avoiding the literal because I knew it would be non-null (I
believe D null terminates literals) and because I want to be able to
detect these states on more than just empty string literals.
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
