The Matrix to end all Matrix classes (Let's dream!)

[Bill Baxter]

Robert DaSilva wrote:

Hey there Robert, I took Don's original message to be asking about what 
we could do *today*.  There are certainly some features in the works 
that will address a number of my points, and some potential additions 
that with a reasonable proposal, and enough lobbying and support might 
be added sometime in the future.  But that's not what I was writing about.

--bb

> Bill Baxter wrote:
>> Dan wrote: 
>>> D's slices already perform 90% of the stuff we want in order to
>>> achieve a Matrix.  You more or less just want a standard library that
>>> lets you do it, right?
>> I'd say it lets you do about 50% of the stuff you want for a Matrix, but
>> putting a single percentage figure on it is not really possible, because
>> different features have different importance to different users.
>>
>> In particular:
>> 1) $ can't be used for opIndex or opSlice in user-classes.
> 
> I think there's a proposal for that already.
> 
>> 2) D lacks a clean syntax for slices of multiple dimensions.  opSlice
>> calls must have one and only one ".."
> 
> Can you propose a syntax for that?
> 
>> 3) D lacks a way to return a reference.  opIndexAssign only takes you so
>> far.
> 
> Isn't that in the works?
> 
>> 4) D lacks a way to transparently reference count memory.  (No
>> equivalent of struct copy constructors or destructors)
> 
> Can you think of a something that really need reference counting when
> you have GC?
> 
>> 5) D lacks a way to pass by const-reference (even in D2 -- but
>> presumably this is just a bug in the D2.x compiler)
> 
> The ref parameter storage type combined with const doesn't make sense,
> use in and let the complier decide how to pass it.