View mode: basic / threaded / horizontal-split · Log in · Help
June 11, 2005
opSliceAssign?
Anyone ever notice that there seems to be one indexing operator missing? 
Note the uses of int[] x:

int[] x=new int[5];

int y=x[2]; // opIndex

x[3]=4; // opIndexAssign

int[] y=x[]; // opSlice()

int[] z=new int[5];
z[2..4]=x[2..4] // opSlice(i, j)

x[]=5; // hello, what's this?
x[2..4]=10; // and this?

You can't use the two forms of opSlice as lvalues, just as you can't use 
opIndex as an lvalue.  So there needs to be a new operator - opSliceAssign - 
with two forms, [] and [i..j], in order to complete the set.
June 11, 2005
Re: opSliceAssign?
On Sat, 11 Jun 2005 17:41:59 -0400, Jarrett Billingsley wrote:

> Anyone ever notice that there seems to be one indexing operator missing? 
> Note the uses of int[] x:
> 
> int[] x=new int[5];
> 
> int y=x[2]; // opIndex
> 
> x[3]=4; // opIndexAssign
> 
> int[] y=x[]; // opSlice()
> 
> int[] z=new int[5];
> z[2..4]=x[2..4] // opSlice(i, j)
> 
> x[]=5; // hello, what's this?
> x[2..4]=10; // and this?
> 
> You can't use the two forms of opSlice as lvalues, just as you can't use 
> opIndex as an lvalue.  So there needs to be a new operator - opSliceAssign - 
> with two forms, [] and [i..j], in order to complete the set.

This has been noted before.

To implement this obvious omission however, would weaken Walter's case
against opAssign. I know we already have opIndexAssign, which in light of
the objections to opAssign is an anomaly, so I can't see opSliceAssign
gaining much favour over at DigitalMars. Yet it is an obvious improvement
to the language.

-- 
Derek Parnell
Melbourne, Australia
12/06/2005 9:26:35 AM
June 12, 2005
Re: opSliceAssign?
"Derek Parnell" <derek@psych.ward> wrote in message 
news:1iaq5xnvxkeug.10vcqukxpt0q4$.dlg@40tude.net...
> To implement this obvious omission however, would weaken Walter's case
> against opAssign. I know we already have opIndexAssign, which in light of
> the objections to opAssign is an anomaly, so I can't see opSliceAssign
> gaining much favour over at DigitalMars. Yet it is an obvious improvement
> to the language.

I don't really see why it would even be an issue.  It's an obvious omission 
which would easily be fixed.  It seems stupid to me that a useful feature 
would be left out of the language because of the creator's personal vendetta 
against another possible feature.
June 13, 2005
Re: opSliceAssign?
Derek Parnell wrote:
> On Sat, 11 Jun 2005 17:41:59 -0400, Jarrett Billingsley wrote:
> 
> 
>>Anyone ever notice that there seems to be one indexing operator missing? 
>>Note the uses of int[] x:
>>
>>int[] x=new int[5];
>>
>>int y=x[2]; // opIndex
>>
>>x[3]=4; // opIndexAssign
>>
>>int[] y=x[]; // opSlice()
>>
>>int[] z=new int[5];
>>z[2..4]=x[2..4] // opSlice(i, j)
>>
>>x[]=5; // hello, what's this?
>>x[2..4]=10; // and this?
>>
>>You can't use the two forms of opSlice as lvalues, just as you can't use 
>>opIndex as an lvalue.  So there needs to be a new operator - opSliceAssign - 
>>with two forms, [] and [i..j], in order to complete the set.
> 
> 
> This has been noted before.
> 
> To implement this obvious omission however, would weaken Walter's case
> against opAssign. I know we already have opIndexAssign, which in light of
> the objections to opAssign is an anomaly, so I can't see opSliceAssign
> gaining much favour over at DigitalMars. Yet it is an obvious improvement
> to the language.
> 

However opAssign makes no sense when it applies to a class in the 
hierarchy of the current class.  If it was allowed you could make a 
reference unassignable.


class C
{
  C opAssign( C other ) {}
}


C var ;
var = new C();
// actually the opAssign is called here, barring a special case check 
for null

var = new C() ;
// not assignable any more, the null method above is called

These semantic holes are not trivial, imo.  I dont think tons of special 
checks by the compiler are worth the trivial syntactical sugar added versus

var.value = new C();
var.value = new D();

-DavidM
June 13, 2005
Re: opSliceAssign?
In article <d8k57n$1rrq$1@digitaldaemon.com>, David Medlock says...
>
>Derek Parnell wrote:
>> On Sat, 11 Jun 2005 17:41:59 -0400, Jarrett Billingsley wrote:
>> 
>> 
>>>Anyone ever notice that there seems to be one indexing operator missing? 
>>>Note the uses of int[] x:
>>>
>>>int[] x=new int[5];
>>>
>>>int y=x[2]; // opIndex
>>>
>>>x[3]=4; // opIndexAssign
>>>
>>>int[] y=x[]; // opSlice()
>>>
>>>int[] z=new int[5];
>>>z[2..4]=x[2..4] // opSlice(i, j)
>>>
>>>x[]=5; // hello, what's this?
>>>x[2..4]=10; // and this?
>>>
>>>You can't use the two forms of opSlice as lvalues, just as you can't use 
>>>opIndex as an lvalue.  So there needs to be a new operator - opSliceAssign - 
>>>with two forms, [] and [i..j], in order to complete the set.
>> 
>> 
>> This has been noted before.
>> 
>> To implement this obvious omission however, would weaken Walter's case
>> against opAssign. I know we already have opIndexAssign, which in light of
>> the objections to opAssign is an anomaly, so I can't see opSliceAssign
>> gaining much favour over at DigitalMars. Yet it is an obvious improvement
>> to the language.
>> 
>
>However opAssign makes no sense when it applies to a class in the 
>hierarchy of the current class.  If it was allowed you could make a 
>reference unassignable.
>
>
>class C
>{
>   C opAssign( C other ) {}
>}
>
>
>C var ;
>var = new C();
>// actually the opAssign is called here, barring a special case check 
>for null
>
>var = new C() ;
>// not assignable any more, the null method above is called
>
>These semantic holes are not trivial, imo.  I dont think tons of special 
>checks by the compiler are worth the trivial syntactical sugar added versus
>
>var.value = new C();
>var.value = new D();
>
>-DavidM
June 13, 2005
Re: opSliceAssign?
Oops, sorry for the previous post.

>However opAssign makes no sense when it applies to a class in the 
>hierarchy of the current class.  If it was allowed you could make a 
>reference unassignable.

I agree with you, overriding '=' doesn't make much sense in D. But I believe
someone once suggested to add another operator, for example ':=' like in pascal,
which had the definite meaning 'assign value'. But I'm not sure I think it fits
into the language, though. For example, it would mean there would be two ways of
assigning to an int, both i = 10 and i := 10, and that would probably seem
confusing or ugly to a lot of people.

Nick
June 13, 2005
Re: opSliceAssign?
On Mon, 13 Jun 2005 10:29:10 -0400, David Medlock wrote:

> Derek Parnell wrote:
>> On Sat, 11 Jun 2005 17:41:59 -0400, Jarrett Billingsley wrote:
>> 
>> 
>>>Anyone ever notice that there seems to be one indexing operator missing? 
>>>Note the uses of int[] x:
>>>
>>>int[] x=new int[5];
>>>
>>>int y=x[2]; // opIndex
>>>
>>>x[3]=4; // opIndexAssign
>>>
>>>int[] y=x[]; // opSlice()
>>>
>>>int[] z=new int[5];
>>>z[2..4]=x[2..4] // opSlice(i, j)
>>>
>>>x[]=5; // hello, what's this?
>>>x[2..4]=10; // and this?
>>>
>>>You can't use the two forms of opSlice as lvalues, just as you can't use 
>>>opIndex as an lvalue.  So there needs to be a new operator - opSliceAssign - 
>>>with two forms, [] and [i..j], in order to complete the set.
>> 
>> 
>> This has been noted before.
>> 
>> To implement this obvious omission however, would weaken Walter's case
>> against opAssign. I know we already have opIndexAssign, which in light of
>> the objections to opAssign is an anomaly, so I can't see opSliceAssign
>> gaining much favour over at DigitalMars. Yet it is an obvious improvement
>> to the language.
>> 
> 
> However opAssign makes no sense when it applies to a class in the 
> hierarchy of the current class.

I'm sure I'm being a bit slow on this, but I'm yet to understand the
'universal truth' in that statement. I'm talking about copying values
rather than copying references.

>  If it was allowed you could make a 
> reference unassignable.

Yes, but so what? That would either be a bug or a deliberate act. If a bug,
it would get fixed, otherwise its something that the designer wants. Who am
I to demand that others code like myself?

> 
> class C
> {
>    C opAssign( C other ) {}
> }
> 
> 
> C var ;
> var = new C();
> // actually the opAssign is called here, barring a special case check 
> for null
> 
> var = new C() ;
> // not assignable any more, the null method above is called

Agreed, but so what?

One could also override other operations to do equally stupid things but we
aren't getting all 'holy' about those?

class C
{
 private int x;
 int opAdd (int y)
 {
    return y * -x;
 }
}
C c = new C;
int d = c + 1;

> These semantic holes are not trivial, imo.  I dont think tons of special 
> checks by the compiler are worth the trivial syntactical sugar added versus
> 
> var.value = new C();
> var.value = new D();

With respect to classes, the current semantics for the assign operator only
allows one to assign class references and not class values. Where is the
easy-to-read syntax to allow us to assign class values?

 C c;
 C d;

 d = c; // WRONG, 'cos I want to assign value not reference //
 d.prop = c;  // Only if we define a 'property' setter function.

The problem with this is that there is *no* standard. A simpler,
standardized syntax that tells the reader that I'm assigning the *value* of
one class instance to something would be appreciated.

I'm so stupid to want this? 

If Walter is wise enough to allow hybrid operators like '!is', then
something as commonly used as ':=' should be allowed as an overridable
operation. Maybe it can *only* be an overridable operation in that if there
isn't an opValueAssign function defined then the compiler complains.

I'm not saying that the '=' symbol must or must not be overridable as a
value assignment. I don't give a hoot about that. I'm just saying that a
simple, standardize syntax that implements value assignment for classes
would be a useful language construct. If you are troubled that coders will
get confused between '=' and ':=' then somebody can surely come up with
another acceptable variant. Its a simple concept - copying the value - so
we should be able to have a simple syntax for it.

-- 
Derek Parnell
Melbourne, Australia
14/06/2005 7:05:03 AM
June 14, 2005
Re: opSliceAssign?
Derek Parnell wrote:
> On Mon, 13 Jun 2005 10:29:10 -0400, David Medlock wrote:
>>>
>>>This has been noted before.
>>>
>>>To implement this obvious omission however, would weaken Walter's case
>>>against opAssign. I know we already have opIndexAssign, which in light of
>>>the objections to opAssign is an anomaly, so I can't see opSliceAssign
>>>gaining much favour over at DigitalMars. Yet it is an obvious improvement
>>>to the language.
>>>
>>
>>However opAssign makes no sense when it applies to a class in the 
>>hierarchy of the current class.
> 
> 
> I'm sure I'm being a bit slow on this, but I'm yet to understand the
> 'universal truth' in that statement. I'm talking about copying values
> rather than copying references.

Except that classes already copy references and struct values. What you 
are proposing is a change where an existing _intrinsic_ operation is 
changed.  Changing references to variables is the meat and potatoes of
imperative programming.  Its vital we know when values are passed by 
reference or by value.

> 
> 
>> If it was allowed you could make a 
>>reference unassignable.
> 
> 
> Yes, but so what? That would either be a bug or a deliberate act. If a bug,
> it would get fixed, otherwise its something that the designer wants. Who am
> I to demand that others code like myself?

So what?  That is a coding nightmare.  Simple assigning an existing 
reference to a new Object requires you to jump through hoops?

If this happened It would need to be another operator or risk having to 
read back through classes each time an assignment is made just to check 
and see if you are calling functions in the background.

I doubt its troubling to most that an assignment assigns a value....

> 
> 
>>class C
>>{
>>   C opAssign( C other ) {}
>>}
>>
>>
>>C var ;
>>var = new C();
>>// actually the opAssign is called here, barring a special case check 
>>for null
>>
>>var = new C() ;
>>// not assignable any more, the null method above is called
> 
> 
> Agreed, but so what?
> 
> One could also override other operations to do equally stupid things but we
> aren't getting all 'holy' about those?

You have lost me here.  I now have a reference I cannot reassign and you 
are talking about holiness?

> 
>  class C
>  {
>   private int x;
>   int opAdd (int y)
>   {
>      return y * -x;
>   }
>  }
>  C c = new C;
>  int d = c + 1;
> 
> 
>>These semantic holes are not trivial, imo.  I dont think tons of special 
>>checks by the compiler are worth the trivial syntactical sugar added versus
>>
>>var.value = new C();
>>var.value = new D();
> 
> 
> With respect to classes, the current semantics for the assign operator only
> allows one to assign class references and not class values. Where is the
> easy-to-read syntax to allow us to assign class values?
> 
>   C c;
>   C d;
> 
>   d = c; // WRONG, 'cos I want to assign value not reference //
>   d.prop = c;  // Only if we define a 'property' setter function.
> 
> The problem with this is that there is *no* standard. A simpler,
> standardized syntax that tells the reader that I'm assigning the *value* of
> one class instance to something would be appreciated.
> 
> I'm so stupid to want this? 
> 
Looking over my post I don't see any part where I called it 'stupid'.

And I havent even touched on inout/out parameters. That is a whole 
different mess of worms.
(Think derived classes with opAssign passed to a base function which 
requires *true* assignment to a base class....BOOOM!)

The := operator would be a workable solution, because it is clearly an 
operation you have defined and yet cannot prevent reassigning the reference.

At any rate I still don't see why you seem upset over this...

-DavidM
June 14, 2005
Re: opSliceAssign?
On Mon, 13 Jun 2005 22:55:48 -0400, David Medlock wrote:

I'm beginning to suspect that what we have here is a failure to
communicate. It would seem that I'm not really understanding you and that
you are not really understanding me.

> Derek Parnell wrote:
>> On Mon, 13 Jun 2005 10:29:10 -0400, David Medlock wrote:
>>>>
>>>>This has been noted before.
>>>>
>>>>To implement this obvious omission however, would weaken Walter's case
>>>>against opAssign. I know we already have opIndexAssign, which in light of
>>>>the objections to opAssign is an anomaly, so I can't see opSliceAssign
>>>>gaining much favour over at DigitalMars. Yet it is an obvious improvement
>>>>to the language.
>>>>
>>>
>>>However opAssign makes no sense when it applies to a class in the 
>>>hierarchy of the current class.
>> 
>> I'm sure I'm being a bit slow on this, but I'm yet to understand the
>> 'universal truth' in that statement. I'm talking about copying values
>> rather than copying references.
> 
> Except that classes already copy references and struct values.

I know. I wouldn't want to change that either. 

To my knowledge, by default the '=' operator means 'copy reference' when
applied to classes and arrays, and it means 'copy value' when applied to
structs and intrinsic items (ints, etc...)

So given the code below...

 a = b;

Is this a value or reference assignment? Of course we don't know because
there is not enough information local to the code to tell. In other words,
the '=' is ambiguous until we have context information.

> What you 
> are proposing is a change where an existing _intrinsic_ operation is 
> changed.

No, that is not a true statement. I am not saying that '=' should be
changed to be, by default, a value assignment for classes. I am saying that
*when* one has need to do a value assignment with a class, a simple,
unambiguous, standardized syntax would be an advantage to coders and reader
alike.

>  Changing references to variables is the meat and potatoes of
> imperative programming.  Its vital we know when values are passed by 
> reference or by value.

Exactly my point! Currently it is ambiguous without context.

>> 
>>> If it was allowed you could make a 
>>>reference unassignable.
>> 
>> Yes, but so what? That would either be a bug or a deliberate act. If a bug,
>> it would get fixed, otherwise its something that the designer wants. Who am
>> I to demand that others code like myself?
> 
> So what?  That is a coding nightmare.

Yes it is a coding nightmare. And the author had better have a damned good
reason for doing it too! 

> Simple assigning an existing reference to a new Object requires you
> to jump through hoops?

But simply assigning an existing value to an existing object requires you
to jump through hoops, is okay, right? Of course not. So why can we not
have both pieces of functionality available in our toolkit?

> If this happened It would need to be another operator or risk having to 
> read back through classes each time an assignment is made just to check 
> and see if you are calling functions in the background.

And that argument applies to every type of overloaded operator.

> I doubt its troubling to most that an assignment assigns a value....

But that's the point. It (i.e. '=') doesn't assign a value when we are
talking about classes, it assigns a reference. But you know that. 

> 
>> 
>>>class C
>>>{
>>>   C opAssign( C other ) {}
>>>}
>>>
>>>
>>>C var ;
>>>var = new C();
>>>// actually the opAssign is called here, barring a special case check 
>>>for null
>>>
>>>var = new C() ;
>>>// not assignable any more, the null method above is called
>> 
>> Agreed, but so what?
>> 
>> One could also override other operations to do equally stupid things but we
>> aren't getting all 'holy' about those?
> 
> You have lost me here.  I now have a reference I cannot reassign and you 
> are talking about holiness?

And you are not understanding me... I'll try again in plainer speech.

Fact: It is possible to write counter productive algorithms for any of the
overloadable operators. In that case, why is the assignment operator
singled out as the one that is never to be overloaded just because somebody
could abuse it? If that was a valid reason, then none of the operators
should be overloadable.

>> 
>>  class C
>>  {
>>   private int x;
>>   int opAdd (int y)
>>   {
>>      return y * -x;
>>   }
>>  }
>>  C c = new C;
>>  int d = c + 1;
>> 
>>>These semantic holes are not trivial, imo.  I dont think tons of special 
>>>checks by the compiler are worth the trivial syntactical sugar added versus
>>>
>>>var.value = new C();
>>>var.value = new D();
>> 
>> With respect to classes, the current semantics for the assign operator only
>> allows one to assign class references and not class values. Where is the
>> easy-to-read syntax to allow us to assign class values?
>> 
>>   C c;
>>   C d;
>> 
>>   d = c; // WRONG, 'cos I want to assign value not reference //
>>   d.prop = c;  // Only if we define a 'property' setter function.
>> 
>> The problem with this is that there is *no* standard. A simpler,
>> standardized syntax that tells the reader that I'm assigning the *value* of
>> one class instance to something would be appreciated.
>> 
>> I'm so stupid to want this? 
>> 
> Looking over my post I don't see any part where I called it 'stupid'.

No you didn't. And I'm sorry you thought that I said you did. The
introduction of that term is solely my responsibility. Let me restate it in
other words...

It would appear, on the basis that more knowledgeable people than myself
are putting forward strong arguments for continuing the ban on overloading
the '=' operator, that I am very much mistaken in thinking that the concept
of having a simple, standard, unambiguous operator that designates
copy-value as an overloadable operator, is a good idea.


> And I havent even touched on inout/out parameters. That is a whole 
> different mess of worms.

I believe the current term is "that opens a Pandora's box of worms" ;-)

> (Think derived classes with opAssign passed to a base function which 
> requires *true* assignment to a base class....BOOOM!)

Again, there would have to be a rock-solid reason for doing that, but just
because I can't think of one right now, doesn't mean that there isn't one.
Also, I'm *NOT* talking about overloading the '=' operator for classes. I'm
talking conceptually. 

> The := operator would be a workable solution, because it is clearly an 
> operation you have defined and yet cannot prevent reassigning the reference.

Great.

> At any rate I still don't see why you seem upset over this...

Because I'm looking through a window and I see a smudge. I want to clean
it.

I've written a library that started using structs, because it is
essentially a set of value-based entities that the library deals with.
However, passing large structs by value to functions looked like becoming a
performance issue. So I converted to using classes, and had to change a lot
of code. In the end I settled on property setters as the mechanism, but it
isn't standard.

So instead of  ....

  Foo a;
  Bar b;
  . . .
  a = b;

I now have ....

  Foo a = new Foo;
  Bar b = new Bar;
  . . .
  a.Value = b;

And I don't see how this has improved legibility. I might go back to
structs and have them passed by address/reference, but then I've read-only
issues.

-- 
Derek
Melbourne, Australia
14/06/2005 2:08:57 PM
June 14, 2005
Re: opSliceAssign?
Derek Parnell wrote:
<snip>
> To implement this obvious omission however, would weaken Walter's case
> against opAssign. I know we already have opIndexAssign, which in light of
> the objections to opAssign is an anomaly, so I can't see opSliceAssign
> gaining much favour over at DigitalMars. Yet it is an obvious improvement
> to the language.

I'm inclined to disagree.  This is not so much overloading the = 
operator as overloading the use of a slice expression as an lvalue.

Indeed, slices are one things that could make having opAssign confusing. 
 Because you could end up with

    qwert[13..42] = yuiop;

being equivalent to

    qwert.opSlice(13, 42).opAssign(yuiop);

which could lead to counter-intuitive behaviour.  OTOH if we make it 
equivalent to

    qwert.opSliceAssign(yuiop, 13, 42);

then it makes perfect sense.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home