On Fri, 05 Jul 2013 11:39:37 +0100, Dmitry Olshansky
<dmitry.o...@gmail.com> wrote:
05-Jul-2013 13:24, Regan Heath пишет:
On Fri, 05 Jul 2013 10:13:11 +0100, Dmitry Olshansky
<dmitry.o...@gmail.com> wrote:
05-Jul-2013 12:55, Regan Heath пишет:
On Thu, 04 Jul 2013 20:15:08 +0100, Dmitry Olshansky
<dmitry.o...@gmail.com> wrote:
04-Jul-2013 19:00, Regan Heath пишет:
In fact, you can generalise further.
The meaning of if(x) is "compare the value of x with 0" (in C, C++,
.. ).
The value of x for a pointer is the address to which it points.
The value of x for a class reference is the address of the class to
which it refers.
If D's arrays are reference types,
They are not. It's a half-reference no wonder it has a bit of
schizophrenia now and then.
True. The struct which contains the ptr and length is actually a
value
type. I think conceptually however we should be thinking of them as
reference types, because.. the array struct is effectively a
lightweight
wrapper (adding length) around a reference type (ptr).
then IMO they should exhibit the same
behaviour.
The behavior should be the most useful and since arr.length != 0 is
what 99% of time a programmer wants to check.
IMO, the behaviour should be consistent. If you code if (x) then the
compiler will compare 'x' (not a property of x) to 0. Doing anything
else would be inconsistent and unexpected to anyone from a C
background.
Then since slices compared to null by your logic means both ptr and
length equal 0. Completely broken idea hence I'd simply propose to
disable it.
I think I need to clarify.
I am making 3 statements here:
1. Arrays are a thin wrapper around a reference type (ptr) which add
safety.
Rather it packs 2 pointers (pair: ptr, ptr+len), modeling the region in
between.
True, but the actual implementation isn't the issue. The concept of D's
arrays was to wrap pointers in order to make them safer. So,
/conceptually/ an array is a thin wrapper over a pointer. Concept defines
semantics, rather than implementation, IMO :)
2. When you have a thin wrapper you should treat operations on the
wrapper as the wrapped object in the general case.
Continuation of the above stretch.
To be a true wrapper it has to support only the same or subset of
operations. For instance arrays have slicing operation hence it's more
then that.
To my mind wrappers aren't limited in such a way and can add
functionality, the key to me is that they continue to expose the
underlying object, which d's arrays do (in various ways).
R
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
