On Fri, Oct 18, 2013 at 10:04:52PM +0200, Meta wrote:
> On Friday, 18 October 2013 at 19:59:26 UTC, H. S. Teoh wrote:
> >...because it eliminates an unnecessary distinction between an empty sequence and a non-existent sequence (which then leads to similar issues one encounters with null pointers).
> 
> That just seems silly. Surely we all recognize that there's a difference between the empty set and having no set at all, and that it's valuable to be able to distinguish between the two. The empty set is still a set, while nothing is... nothing.

Yes, but if you declare a variable to contain a set, then by definition there is *something*, even if it's an empty set. For there to be nothing, there shouldn't even be a variable in the first place. The fact that the variable exists and has an identifer means that there is *something*. So your argument is moot.


T

-- 
Computers shouldn't beep through the keyhole.

On Friday, 18 October 2013 at 21:15:32 UTC, H. S. Teoh wrote:
> Yes, but if you declare a variable to contain a set, then by definition there is *something*, even if it's an empty set.

Exactly. There is still *something*, even though the set is empty. That is, the set itself.

> For there to be nothing, there shouldn't even be a variable in the first place. The fact that the variable exists and has an identifer means that there is *something*. So your argument is moot.

Not really. Null is a special marker to indicate the absence of a value. There is nothing, as opposed to the previous case.

On Sat, Oct 19, 2013 at 12:04:47AM +0200, Meta wrote:
> On Friday, 18 October 2013 at 21:15:32 UTC, H. S. Teoh wrote:
> >Yes, but if you declare a variable to contain a set, then by definition there is *something*, even if it's an empty set.
> 
> Exactly. There is still *something*, even though the set is empty. That is, the set itself.
> 
> >For there to be nothing, there shouldn't even be a variable in the first place. The fact that the variable exists and has an identifer means that there is *something*. So your argument is moot.
> 
> Not really. Null is a special marker to indicate the absence of a value. There is nothing, as opposed to the previous case.

That's if you consider a set to be a reference type. Then you can say
that the reference may be referring to something (which may be empty or
not), or it can refer to nothing (null).

But if the set is a value type, then there is no such thing as null, only empty.


T

-- 
INTEL = Only half of "intelligence".

On Friday, 18 October 2013 at 21:15:32 UTC, H. S. Teoh wrote:
> On Fri, Oct 18, 2013 at 10:04:52PM +0200, Meta wrote:
>> On Friday, 18 October 2013 at 19:59:26 UTC, H. S. Teoh wrote:
>> >...because it eliminates an unnecessary distinction between an
>> >empty sequence and a non-existent sequence (which then leads to
>> >similar issues one encounters with null pointers).
>> 
>> That just seems silly. Surely we all recognize that there's a
>> difference between the empty set and having no set at all, and that
>> it's valuable to be able to distinguish between the two. The empty
>> set is still a set, while nothing is... nothing.
>
> Yes, but if you declare a variable to contain a set, then by definition
> there is *something*, even if it's an empty set. For there to be
> nothing, there shouldn't even be a variable in the first place. The fact
> that the variable exists and has an identifer means that there is
> *something*. So your argument is moot.
>
>
> T

I was simply thinking about sdl where you pass in a rect for the coords to blt one surface to the other. Null/0 means copy the whole thing. Rect is an object but I was thinking what about arrays (empty VS pull a default somewhere). Thats how I came up with this question and the point is I WANT to NOT specify a value so a DYNAMIC SUITABLE default value can be used.

On Sat, Oct 19, 2013 at 12:45:02AM +0200, ProgrammingGhost wrote:
> On Friday, 18 October 2013 at 21:15:32 UTC, H. S. Teoh wrote:
> >On Fri, Oct 18, 2013 at 10:04:52PM +0200, Meta wrote:
> >>On Friday, 18 October 2013 at 19:59:26 UTC, H. S. Teoh wrote:
> >>>...because it eliminates an unnecessary distinction between an empty sequence and a non-existent sequence (which then leads to similar issues one encounters with null pointers).
> >>
> >>That just seems silly. Surely we all recognize that there's a difference between the empty set and having no set at all, and that it's valuable to be able to distinguish between the two. The empty set is still a set, while nothing is... nothing.
> >
> >Yes, but if you declare a variable to contain a set, then by definition there is *something*, even if it's an empty set. For there to be nothing, there shouldn't even be a variable in the first place. The fact that the variable exists and has an identifer means that there is *something*. So your argument is moot.
> >
> >
> >T
> 
> I was simply thinking about sdl where you pass in a rect for the coords to blt one surface to the other. Null/0 means copy the whole thing. Rect is an object but I was thinking what about arrays (empty VS pull a default somewhere). Thats how I came up with this question and the point is I WANT to NOT specify a value so a DYNAMIC SUITABLE default value can be used.

You could use T[]* and pass a null pointer as default?


T

-- 
What is Matter, what is Mind? Never Mind, it doesn't Matter.

> You could use T[]* and pass a null pointer as default?

Yet this answer wasn't on the first page.

I see I can't write fn([1,2]) anymore so I'm unsure how this
solution compares to using Nullable (I can't write fn([1,2]) with
nullable either).

On Friday, 18 October 2013 at 21:15:32 UTC, H. S. Teoh wrote:
> Yes, but if you declare a variable to contain a set, then by definition
> there is *something*, even if it's an empty set. For there to be
> nothing, there shouldn't even be a variable in the first place. The fact
> that the variable exists and has an identifer means that there is
> *something*. So your argument is moot.
>
>
> T

We can declare a variable to contain an object, and there can still not be an object there.

You're trying to make arrays non-nullable. Which I suppose isn't so bad, it is a structure after all. Why do we even allow checking against null, can't do it with int or bool. (ok, I know, breaks code).

On Friday, 18 October 2013 at 10:44:11 UTC, Regan Heath wrote:
> 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.

In C# code null strings are a plague. Most of the time you don't need them, but still must check for them just in order to not get an exception. Also business logic makes no difference between null and empty - both of them are just "no data", so you end up typing if(string.IsNullOrEmpty(mystr)) every time everywhere. And, yeah, only one small feature in this big mess ever needs to differentiate between null and empty. I found this one case trivially implementable, but nulls still plague all remaining code.

> 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.

This is a horrible design. You better throw an exception on eof instead of null: this null will break the caller anyway possibly in a contrived way. It works if you read one line per loop cycle, but if you read several lines and assume they're not null (some multiline data format), you're screwed or your code becomes littered with null checks, but who accounts for all alternative scenarios from the start?

If readline returns empty string on eof, I don't expect it to break any business logic. If the empty string doesn't match, ok, no match, continue. You can check for eof equally, but at *your* discretion, not when the external data wants you to do it.

> 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.

I believe there's no problem domain, which would like to differentiate between null and empty string instead of treating them as "no data".

Jesse Phillips:

> Why do we even allow checking against null, can't do it
> with int or bool. (ok, I know, breaks code).

Sometimes breaking code is acceptable.

Bye,
bearophile

On Friday, 18 October 2013 at 17:59:17 UTC, Max Samukha wrote:
> On Friday, 18 October 2013 at 16:55:19 UTC, Andrei Alexandrescu wrote:
>>
>> Fair point. I just gave one possible alternative out of many. Thing is, relying on client code to distinguish subtleties between empty and null strings is fraught with dangers.
>>
>> Andrei
>
> I agree. Thinking about your variant of readln - it's ok to use [] as the value indicating EOF, since it is not included in the value set of type "line" as you define it.

No, if the last line is empty, it has no new line character(s) at the end, and is as empty, as it can get.