May 16, 2012
On 16-05-2012 18:12, Gor Gyolchanyan wrote:
>
> On Wed, May 16, 2012 at 7:22 PM, Steven Schveighoffer
> <schveiguy@yahoo.com <mailto:schveiguy@yahoo.com>> wrote:
>
>     On Wed, 16 May 2012 10:04:50 -0400, Gor Gyolchanyan
>     <gor.f.gyolchanyan@gmail.com <mailto:gor.f.gyolchanyan@gmail.com>>
>     wrote:
>
>         On Wed, May 16, 2012 at 5:25 PM, Steven Schveighoffer
>         <schveiguy@yahoo.com <mailto:schveiguy@yahoo.com>>wrote:
>
>
>
>             I don't see a "problem" anywhere.  The current system is
>             perfect for what
>             it needs to do.
>
>
>         Aside from the string problem the very existence of this debate
>         exposes a
>         fundamental flaw in the entire software engineering industry:
>         heavy usage
>         of ancient crap.
>         If some library is so damned hard to refresh, then something's
>         terribly
>         wrong with it. It's about damned time ancient libraries are
>         thrown away.
>
>
>     It's quite difficult to "throw out" OS libraries that you need ;)
>       printf is hardly the only C interface that requires
>     null-terminated strings.
>
>     D is a pragmatic language, not an ideological one.
>
>     -Steve
>
>
> Dear Steven and Alex. By no means, I say, that every ancient technology
> is to be thrown out at once. That's a technological suicide. What I
> mean, that knowing, that the technology is ancient, we should at least
> put some effort to gradually move away from it. If it needs to be done -
> it needs to be done. If it happens to be expensive to do - oh, well. I
> understand, that the human resources are limited, but hanging on ancient
> technology for _too_ long is a death wish for any new technology.
>
> --
> Bye,
> Gor Gyolchanyan.

Yes, but the thing is, throwing out null-terminated strings is not something you do gradually - you have to do it from one day to another. It's such a simple feature that you either have it or you don't.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org
May 16, 2012
On Wed, May 16, 2012 at 8:16 PM, Alex Rønne Petersen <alex@lycus.org> wrote:

> On 16-05-2012 18:12, Gor Gyolchanyan wrote:
>
>>
>> On Wed, May 16, 2012 at 7:22 PM, Steven Schveighoffer <schveiguy@yahoo.com <mailto:schveiguy@yahoo.com>> wrote:
>>
>>    On Wed, 16 May 2012 10:04:50 -0400, Gor Gyolchanyan
>>    <gor.f.gyolchanyan@gmail.com <mailto:gor.f.gyolchanyan@**gmail.com<gor.f.gyolchanyan@gmail.com>
>> >>
>>
>>    wrote:
>>
>>        On Wed, May 16, 2012 at 5:25 PM, Steven Schveighoffer
>>        <schveiguy@yahoo.com <mailto:schveiguy@yahoo.com>>**wrote:
>>
>>
>>
>>
>>            I don't see a "problem" anywhere.  The current system is
>>            perfect for what
>>            it needs to do.
>>
>>
>>        Aside from the string problem the very existence of this debate
>>        exposes a
>>        fundamental flaw in the entire software engineering industry:
>>        heavy usage
>>        of ancient crap.
>>        If some library is so damned hard to refresh, then something's
>>        terribly
>>        wrong with it. It's about damned time ancient libraries are
>>        thrown away.
>>
>>
>>    It's quite difficult to "throw out" OS libraries that you need ;)
>>      printf is hardly the only C interface that requires
>>    null-terminated strings.
>>
>>    D is a pragmatic language, not an ideological one.
>>
>>    -Steve
>>
>>
>> Dear Steven and Alex. By no means, I say, that every ancient technology is to be thrown out at once. That's a technological suicide. What I mean, that knowing, that the technology is ancient, we should at least put some effort to gradually move away from it. If it needs to be done - it needs to be done. If it happens to be expensive to do - oh, well. I understand, that the human resources are limited, but hanging on ancient technology for _too_ long is a death wish for any new technology.
>>
>> --
>> Bye,
>> Gor Gyolchanyan.
>>
>
> Yes, but the thing is, throwing out null-terminated strings is not something you do gradually - you have to do it from one day to another. It's such a simple feature that you either have it or you don't.
>
>
> --
> Alex Rønne Petersen
> alex@lycus.org
> http://lycus.org
>

if("" != []) assert("".length != 0);

Will this fail?

-- 
Bye,
Gor Gyolchanyan.


May 16, 2012
On Wed, 16 May 2012 12:21:27 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:

>
> if("" != []) assert("".length != 0);
>
> Will this fail?

No.  Ambiguities only come into play when you use 'is'.  I highly recommend not using 'is' for arrays unless you really have a good reason, since two slices can be 'equal' but 'point at different instances'.

For example:

auto str = "abcabc";
assert(str[0..3] == str[3..$]); // pass
assert(str[0..3] is str[3..$]); // fail

which is very counterintuitive.

-Steve
May 16, 2012
On Wed, May 16, 2012 at 01:07:54PM -0400, Steven Schveighoffer wrote: [...]
> For example:
> 
> auto str = "abcabc";
> assert(str[0..3] == str[3..$]); // pass
> assert(str[0..3] is str[3..$]); // fail
> 
> which is very counterintuitive.
[...]

I don't find that counterintuitive at all. To me, 'is' concerns memory identity: are the two things actually one and the same _in memory_? (In this case, no, because they are different chunks of memory that just happens to contain the same values.) Whereas '==' concerns logical identity: do the two things represent the same logical entity? (In this case, yes, these two arrays contain exactly the same elements.)

I'd argue that 99% of the time, what you want is logical identity (i.e.,
==), not memory identity.


T

-- 
Stop staring at me like that! You'll offend... no, you'll hurt your eyes!
May 16, 2012
On Wed, May 16, 2012 at 9:07 PM, Steven Schveighoffer <schveiguy@yahoo.com>wrote:

> On Wed, 16 May 2012 12:21:27 -0400, Gor Gyolchanyan < gor.f.gyolchanyan@gmail.com> wrote:
>
>
>> if("" != []) assert("".length != 0);
>>
>> Will this fail?
>>
>
> No.  Ambiguities only come into play when you use 'is'.  I highly recommend not using 'is' for arrays unless you really have a good reason, since two slices can be 'equal' but 'point at different instances'.
>
> For example:
>
> auto str = "abcabc";
> assert(str[0..3] == str[3..$]); // pass
> assert(str[0..3] is str[3..$]); // fail
>
> which is very counterintuitive.
>
> -Steve
>

Doesn't assert("".length != 0) look extremely counter-intuitive?

-- 
Bye,
Gor Gyolchanyan.


May 16, 2012
On Wed, May 16, 2012 at 09:17:17PM +0400, Gor Gyolchanyan wrote:
> On Wed, May 16, 2012 at 9:07 PM, Steven Schveighoffer <schveiguy@yahoo.com>wrote:
> 
> > On Wed, 16 May 2012 12:21:27 -0400, Gor Gyolchanyan < gor.f.gyolchanyan@gmail.com> wrote:
> >
> >
> >> if("" != []) assert("".length != 0);
> >>
> >> Will this fail?
> >>
> >
> > No.  Ambiguities only come into play when you use 'is'.  I highly recommend not using 'is' for arrays unless you really have a good reason, since two slices can be 'equal' but 'point at different instances'.
[...]
> Doesn't assert("".length != 0) look extremely counter-intuitive?
[...]

Code:
	import std.stdio;
	void main() {
		writeln("" == []);
		writeln("" != []);
		writeln("".length);
	}

Output:
	true
	false
	0

Where's the problem?


T

-- 
Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.
May 16, 2012
On Wed, 16 May 2012 13:16:36 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:

> On Wed, May 16, 2012 at 01:07:54PM -0400, Steven Schveighoffer wrote:
> [...]
>> For example:
>>
>> auto str = "abcabc";
>> assert(str[0..3] == str[3..$]); // pass
>> assert(str[0..3] is str[3..$]); // fail
>>
>> which is very counterintuitive.
> [...]
>
> I don't find that counterintuitive at all. To me, 'is' concerns memory
> identity: are the two things actually one and the same _in memory_? (In
> this case, no, because they are different chunks of memory that just
> happens to contain the same values.) Whereas '==' concerns logical
> identity: do the two things represent the same logical entity? (In this
> case, yes, these two arrays contain exactly the same elements.)
>
> I'd argue that 99% of the time, what you want is logical identity (i.e.,
> ==), not memory identity.

What's counter intuitive is if you use null as a 'special marker', then you use == in most cases, but that one case where you want to 'check for the special marker', in which case you *have* to use is.

-Steve
May 16, 2012
On Wed, 16 May 2012 13:17:17 -0400, Gor Gyolchanyan <gor.f.gyolchanyan@gmail.com> wrote:

> On Wed, May 16, 2012 at 9:07 PM, Steven Schveighoffer
> <schveiguy@yahoo.com>wrote:
>
>> On Wed, 16 May 2012 12:21:27 -0400, Gor Gyolchanyan <
>> gor.f.gyolchanyan@gmail.com> wrote:
>>
>>
>>> if("" != []) assert("".length != 0);
>>>
>>> Will this fail?
>>>
>>
>> No.  Ambiguities only come into play when you use 'is'.  I highly
>> recommend not using 'is' for arrays unless you really have a good reason,
>> since two slices can be 'equal' but 'point at different instances'.
>>
>> For example:
>>
>> auto str = "abcabc";
>> assert(str[0..3] == str[3..$]); // pass
>> assert(str[0..3] is str[3..$]); // fail
>>
>> which is very counterintuitive.
>>
>> -Steve
>>
>
> Doesn't assert("".length != 0) look extremely counter-intuitive?

That assert would always fail, if the if statement would ever succeed.  It doesn't look counter-intuitive, it looks like a bug!

You basically said:

if(0) assert("".length != 0);

-Steve
May 16, 2012
On Wed, May 16, 2012 at 01:36:27PM -0400, Steven Schveighoffer wrote:
> On Wed, 16 May 2012 13:16:36 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx> wrote:
> 
> >On Wed, May 16, 2012 at 01:07:54PM -0400, Steven Schveighoffer wrote: [...]
> >>For example:
> >>
> >>auto str = "abcabc";
> >>assert(str[0..3] == str[3..$]); // pass
> >>assert(str[0..3] is str[3..$]); // fail
> >>
> >>which is very counterintuitive.
> >[...]
> >
> >I don't find that counterintuitive at all. To me, 'is' concerns memory identity: are the two things actually one and the same _in memory_? (In this case, no, because they are different chunks of memory that just happens to contain the same values.) Whereas '==' concerns logical identity: do the two things represent the same logical entity? (In this case, yes, these two arrays contain exactly the same elements.)
> >
> >I'd argue that 99% of the time, what you want is logical identity
> >(i.e., ==), not memory identity.
> 
> What's counter intuitive is if you use null as a 'special marker', then you use == in most cases, but that one case where you want to 'check for the special marker', in which case you *have* to use is.
[...]

It depends upon one's mental model of what an array is.

If you think of an array as a container that exists apart from its contents, then you'd expect null != [] because null means even the container itself doesn't exist, whereas [] means the container exists but contains nothing.

However, if you regard the array simply as the sum total of its contents, then you'd expect null == [] because there is no container to speak of, either there are elements, or there are none. When there are no elements, there is also no array (or equivalently, the array is empty). Therefore, null and [] are the same thing.

It seems that D takes the latter view, at least as far as == is concerned. Thus, to distinguish between null and [], one has to bypass == and use 'is' (i.e., open up the hood of the mental model of an array, and look into its actual implementation).


T

-- 
Ignorance is bliss... but only until you suffer the consequences!
May 16, 2012
On 16-05-2012 19:36, Steven Schveighoffer wrote:
> On Wed, 16 May 2012 13:16:36 -0400, H. S. Teoh <hsteoh@quickfur.ath.cx>
> wrote:
>
>> On Wed, May 16, 2012 at 01:07:54PM -0400, Steven Schveighoffer wrote:
>> [...]
>>> For example:
>>>
>>> auto str = "abcabc";
>>> assert(str[0..3] == str[3..$]); // pass
>>> assert(str[0..3] is str[3..$]); // fail
>>>
>>> which is very counterintuitive.
>> [...]
>>
>> I don't find that counterintuitive at all. To me, 'is' concerns memory
>> identity: are the two things actually one and the same _in memory_? (In
>> this case, no, because they are different chunks of memory that just
>> happens to contain the same values.) Whereas '==' concerns logical
>> identity: do the two things represent the same logical entity? (In this
>> case, yes, these two arrays contain exactly the same elements.)
>>
>> I'd argue that 99% of the time, what you want is logical identity (i.e.,
>> ==), not memory identity.
>
> What's counter intuitive is if you use null as a 'special marker', then
> you use == in most cases, but that one case where you want to 'check for
> the special marker', in which case you *have* to use is.
>
> -Steve

I guess we can conclude that one should not use 'null' or 'is' for arrays unless absolutely necessary. '[]' and '==' should probably do for the majority of code.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org