Operator overhaul

Christopher Wright dhasenan at gmail.com
Sat Nov 1 10:54:46 PDT 2008


Bill Baxter wrote:
> (Reply to message on d.announce)
> 
> On Wed, Oct 22, 2008 at 9:36 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> Jason House wrote:
> 
>>>> Is there a good reason why it shouldn't be possible to use opAssign as
>>>> a replacement for opIndexAssign?
>>>>
>>>> --bb
>>> opindexAssign will still be needed when opindex has a non-ref return type.
>> I think the entire operator paraphernalia is due for a serious overhaul.
> 
> O_o!  Oh noohs!  We may have to start calling it the "E" language soon.
> 
> Seriously, though, if the overhaul makes it possible to do multiple
> slices with multiple $'s, then I'm all for it.
> As in   hyperArray[$-1,  1..$,  0..$-2]
> Even better would be python's "just leave it out" slicing:
> As in   hyperArray[$-1,  1..,  ..$-2]
> 
> It's a bit easier to read in my eyes.
> 
> There was also the stuff discussed before about passing in the op as a
> delegate or template parameter to give the class designer a chance to
> run some pre- or post- op code as desired.  Or rewriting x+=y type ops
> to be x=x+y
> 
> So we have:
> 1. multiple slice indexing
> 2. generalized $ indexing
> 3. generalized op execution
> 
> Any other operator-related issues?
> 
> --bb

I can never remember how the values for comparison work. An enum 
somewhere (except that's a new type, so just constants):

struct Comparison
{
	const int LeftIsGreater = -1;
	const int Equal = 0;
	const int RightIsGreater = 1;
}

That's simple, it doesn't require any compiler changes, and it'll save 
me some headaches.



More information about the Digitalmars-d mailing list