How do I find out if null was passed in? As you can guess I wasn't happy with the current behavior.

Code:

	import std.stdio;

	void main() {

		fn([1,2]);
		fn(null);
		fn([]);
	}
	void fn(int[] v) {
		writeln("-");
		if(v==null)
			writeln("Use default");
		foreach(e; v)
			writeln(e);
	}

Output

	-
	1
	2
	-
	Use default
	-
	Use default

Sorry I misspoke. I meant to say empty array or not null passed in. The 3rd call to fn is what I didn't like.

On Thursday, 17 October 2013 at 22:50:22 UTC, ProgrammingGhost wrote:
> How do I find out if null was passed in?

try if(v is null) { use default }

if all you care about is if there's contents, I like to use if(v.length) {}

On Thursday, 17 October 2013 at 23:00:12 UTC, Adam D. Ruppe wrote:
> On Thursday, 17 October 2013 at 22:50:22 UTC, ProgrammingGhost wrote:
>> How do I find out if null was passed in?
>
> try if(v is null) { use default }
>
> if all you care about is if there's contents, I like to use if(v.length) {}

Which is ultimately wrong as equality shouldn't test for identity.

On Thursday, 17 October 2013 at 23:00:12 UTC, Adam D. Ruppe wrote:
> On Thursday, 17 October 2013 at 22:50:22 UTC, ProgrammingGhost wrote:
>> How do I find out if null was passed in?
>
> try if(v is null) { use default }
>
> if all you care about is if there's contents, I like to use if(v.length) {}

is null still treats [] as null. I tried && !is [] for fun and it didnt worth either (null is [])

On Thursday, 17 October 2013 at 22:50:22 UTC, ProgrammingGhost wrote:
> How do I find out if null was passed in? As you can guess I wasn't happy with the current behavior.
>
> Code:
>
> 	import std.stdio;
>
> 	void main() {
>
> 		fn([1,2]);
> 		fn(null);
> 		fn([]);
> 	}
> 	void fn(int[] v) {
> 		writeln("-");
> 		if(v==null)
> 			writeln("Use default");
> 		foreach(e; v)
> 			writeln(e);
> 	}
>
> Output
>
> 	-
> 	1
> 	2
> 	-
> 	Use default
> 	-
> 	Use default

On Thursday, 17 October 2013 at 22:51:24 UTC, ProgrammingGhost wrote:
> Sorry I misspoke. I meant to say empty array or not null passed in. The 3rd call to fn is what I didn't like.

null implicitly converts to []. You can't distinguish them in fn.

You could add an overload for typeof(null), but that only catches the literal null, probably not what you'd expect:

import std.stdio;
void fn(typeof(null) v) {
	writeln("-");
	writeln("Use default");
}
void fn(int[] v) {
	writeln("-");
	foreach(e; v)
		writeln(e);
}
void main() {
	fn([1,2]);
	fn(null);
	fn([]);
	int[] x = null;
	fn(x);
}
----
-
1
2
-
Use default
-
-

On Thursday, 17 October 2013 at 23:14:51 UTC, anonymous wrote:
> On Thursday, 17 October 2013 at 22:50:22 UTC, ProgrammingGhost wrote:
>> How do I find out if null was passed in? As you can guess I wasn't happy with the current behavior.
>>
>> Code:
>>
>> 	import std.stdio;
>>
>> 	void main() {
>>
>> 		fn([1,2]);
>> 		fn(null);
>> 		fn([]);
>> 	}
>> 	void fn(int[] v) {
>> 		writeln("-");
>> 		if(v==null)
>> 			writeln("Use default");
>> 		foreach(e; v)
>> 			writeln(e);
>> 	}
>>
>> Output
>>
>> 	-
>> 	1
>> 	2
>> 	-
>> 	Use default
>> 	-
>> 	Use default
>
> On Thursday, 17 October 2013 at 22:51:24 UTC, ProgrammingGhost wrote:
>> Sorry I misspoke. I meant to say empty array or not null passed in. The 3rd call to fn is what I didn't like.
>
> null implicitly converts to []. You can't distinguish them in fn.
>
> You could add an overload for typeof(null), but that only catches the literal null, probably not what you'd expect:
>
> import std.stdio;
> void fn(typeof(null) v) {
> 	writeln("-");
> 	writeln("Use default");
> }
> void fn(int[] v) {
> 	writeln("-");
> 	foreach(e; v)
> 		writeln(e);
> }
> void main() {
> 	fn([1,2]);
> 	fn(null);
> 	fn([]);
> 	int[] x = null;
> 	fn(x);
> }
> ----
> -
> 1
> 2
> -
> Use default
> -
> -

Overloads are acceptable. But that behavior is odd although I do understand its being passed as value. I guess I have to suck it up and hope this behavior doesn't give me problems.

On Thursday, 17 October 2013 at 23:12:03 UTC, ProgrammingGhost wrote:
> is null still treats [] as null.

blah, you're right. It will at least distinguish it from an empty slice though (like arr[$..$]). I don't think there's any way to tell [] from null except typeof(null) at all. At runtime they're both the same: no contents, so null pointer and zero length.

On Fri, Oct 18, 2013 at 01:27:33AM +0200, Adam D. Ruppe wrote:
> On Thursday, 17 October 2013 at 23:12:03 UTC, ProgrammingGhost wrote:
> >is null still treats [] as null.
> 
> blah, you're right. It will at least distinguish it from an empty slice though (like arr[$..$]). I don't think there's any way to tell [] from null except typeof(null) at all. At runtime they're both the same: no contents, so null pointer and zero length.

I think it's a mistake to rely on the distinction between null and non-null but empty arrays in D. They should be regarded as implementation details that user code shouldn't depend on. If you need to distinguish between arrays that are empty and arrays that are null, consider using Nullable!(T[]) instead.


T

-- 
Curiosity kills the cat. Moral: don't be the cat.

On Fri, 18 Oct 2013 00:32:46 +0100, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Fri, Oct 18, 2013 at 01:27:33AM +0200, Adam D. Ruppe wrote:
>> On Thursday, 17 October 2013 at 23:12:03 UTC, ProgrammingGhost
>> wrote:
>> >is null still treats [] as null.
>>
>> blah, you're right. It will at least distinguish it from an empty
>> slice though (like arr[$..$]). I don't think there's any way to tell
>> [] from null except typeof(null) at all. At runtime they're both the
>> same: no contents, so null pointer and zero length.
>
> I think it's a mistake to rely on the distinction between null and
> non-null but empty arrays in D. They should be regarded as
> implementation details that user code shouldn't depend on. If you need
> to distinguish between arrays that are empty and arrays that are null,
> consider using Nullable!(T[]) instead.

This comes up time and again.  The use of, and ability to distinguish empty from null is very useful.  Yes, you run the risk of things like null pointer exceptions etc, but we have that risk now without the reward of being able to distinguish these cases.

Take this simple design:

  string readline();

This function would like to be able to:
 - return null for EOF
 - return [] for a blank line

but it cannot, because as soon as you write:

  foo(readline())

the null/[] case merges.

There are plenty of other such design/cases that can be imagined, and while you can work around them all they add complexity for zero gain.

A simple pointer can do this.. string cannot, this is sad.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/