• bearophile <bearophileHUGS lycos.com> Mar 07 2010
• "Nick Sabalausky" <a a.a> Mar 09 2010

bearophile <bearophileHUGS lycos.com> writes:

Walter Bright Wrote:

 retard wrote:
 The associative array is a sad type in D. It has nasty semantics. I'd 
 like to see it as a real library defined type with just syntactic sugar 
 for constructing literals. Too bad that's not what Walter thinks.


 Actually, that's how D2 associative arrays are done.


But the point of this thread was not this one :-(
I have added a little enhancement request...
http://d.puremagic.com/issues/show_bug.cgi?id=3889

bearophile

"Nick Sabalausky" <a a.a> writes:

"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:hn0ure$1q0s$1 digitalmars.com...
 Walter Bright Wrote:

 retard wrote:
 The associative array is a sad type in D. It has nasty semantics. I'd
 like to see it as a real library defined type with just syntactic sugar
 for constructing literals. Too bad that's not what Walter thinks.


 Actually, that's how D2 associative arrays are done.


 But the point of this thread was not this one :-(
 I have added a little enhancement request...
 http://d.puremagic.com/issues/show_bug.cgi?id=3889

 bearophile


I had to think about that for awhile. Frankly, I'm not sure how I feel about 
it. My thoughts:

- Having zero elements and being null are two conceptually different things. 
Null should not be thought of as meaning "empty", it's more like 
"undefined/unknown/not-applicable". Like in a well-designed database schema: 
Empty string and null string are *deliberately* two different things. It's 
good to be able to distinguish between the two, and we should be able to do 
so.

- A D array is a struct. D structs are value types. Value types in D aren't 
nullable. So it seems weird that this value type can be null.

- The makeup of a D struct is a length and a pointer. Pointers can obviously 
be null. In fact, a D array can be unallocated, in which case the pointer 
part is null. So allowing null for arrays can be considered sugar for 
setting the pointer field to null or comparing the pointer field to null (I 
assume that's how it actually works currently).

- It can be useful in the general case for a value type to, optionally, be 
nullable (Isn't there a Nullable!() wrapper in Phobos for that?) In fact, 
it's useful to have "nullable vs non-nullable" be completely orthogonal to 
"value-type vs reference type". So maybe it would be better to just simply 
have a generalized system of "if you want variable X to be nullable, do this 
/ if you want variable X to be non-nullable, do that". Then, if you have 
reason for your array to be nullable, then you use the standard "nullable 
type" approach that's already applicable to any type, and if you have reason 
to keep it non-nullable, you use the stanard "non-nullable" approach that's 
already applicable to any type.

So, my conclusion on the proposal in the OP:
...Beats me.