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

[Don Clugston]

Bill Baxter wrote:
> Robert DaSilva wrote:
> 
> Hey there Robert, I took Don's original message to be asking about what 
> we could do *today*.

Not really. I was saying, * what does the ultimate goal look like?
And the follow-up question is, * how far are we from the goal?

   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.