Revised RFC on range design for D2

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Fri, Oct 3, 2008 at 11:02 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> Sergey Gromov wrote:
>>> Thu, 02 Oct 2008 15:03:42 -0500,
>>> Andrei Alexandrescu wrote:
>>>> Yah, overloaded ops are due for an overhaul. I'm almost afraid to ask...
>>>> any ideas? :o)
>>>>
>>>> One goal is to fix opIndexAssign and make it work similar to the way it
>>>> works in arrays, e.g. a[b] += c. Indexing into hash tables is a good test
>>>> bed.
>>> What's wrong with a.opIndexAssign(b, a.opIndex(b) + c)?
>> One problem is that for a hashtable that does not have b yet, opIndex will
>> throw an exception.
> 
> I don't see why you expect   a[b] += c to work on a key for which a[b]
> is undefined.  If it's undefined how can you increment it?

Because accessing it as an rvalue is different than accessing it as an 
lvalue. You just wrote a very sensible post in the same vein!

> Unless you've defined your accessor for undefined keys to return some
> other value.  And if it returns some other value then Sergey's rule is
> fine.

Yah, in that case things would work. I wouldn't dislike it, but I think 
Walter won't want to make that change.

> Sparse matrices are a good example of a hash-like data-structure that
> should return a default value (namely zero) for unset keys.  For such
> a sparse matrix      a.opIndexAssign(b, a.opIndex(b) + c)   will work
> fine.

Glad you brought sparse arrays up. Yah, it would work if a[b] would 
return a default value instead of throwing.

>> Another problem (assuming the above is fixed) is that b will be looked up
>> twice in the hash.
> 
> That is a problem.  But like Sergey said, if performance is your #1
> concern then return references.

It's one of the concerns. And there are several solutions that make 
everything work, including performance.

> Though, that solution is a little problematic for the sparse matrices.
>  In order to return a reference to an element that didn't previously
> exist, you must create it.  But if you're just scanning through your
> sparse matrix printing out the values with a[b], you don't expect to
> end up with a dense matrix full of zeros!  In a C++ lib you'd probably
> provide an lvalue-returning operator[] and another function that
> returns just an rvalue.

Exactly.

> Ooh, how about passing in the manipulator @= function somehow?  Either
> delegate or template alias param.
> 
> Example for sparse matrix case:
> // Called for  a[b] @= c type operations
> void opIndexUpdate(void delegate(ref ValueType val) updater, uint idx) {
>       float *ptr = getPtrToElement(idx);  // creates new zero element if needed
>       updater(*ptr);
>       // here you can veto the change
>       // or throw an overflow exception
>       // or clamp *ptr
>       // or round it
>       //  or whatever you want...
> }
> 
> Compiler would generate the different updaters needed for the various
> @= operations.
> 
> Maybe with a template alias param there'd maybe be better hope of the
> compiler being able to inline it all, but then you have the no
> inheritance problem.
> 
> void opIndexUpdate(alias updater)(uint idx) {
>       float *ptr = getPtrToElement(idx);  // creates new zero element if needed
>       updater(*ptr);
> }

I am very glad you brought up this idea. I think it can work. I brought 
it up to Walter and Bartosz (in the alias form), and the status was to 
think about it some more. For whatever reason suggestions are viewed 
with increased negativity when coming from me around here, so I often 
wish someone else comes up with it, gets support, Walter implements it, 
and we all get over with. (That's what I hoped for the property thing, 
but that didn't go through.) In general, it's much easier to attack an 
imperfect proposal than to help make it better, and it's all the more 
enticing when it comes from a perceived authority. (Of course the next 
logical step is the question "then why didn't you help my proposal? :o))


Andrei