Derek Parnell wrote:
> On Tue, 17 May 2005 11:12:36 +0900, Mike Parker wrote:

> Ummmm... don't think it does have an opAssign. I wish it did! It would make
> my coding life a lot easier.

Until I read this post I was utterly convinced D does have an opAssign and I was sure I had used it in my code. Going back and reading the language reference and looking at the code in question, I was wrong on both counts. So why don't we have an opAssign?

On Wed, 18 May 2005 15:39:21 +0900, Mike Parker wrote:

> Derek Parnell wrote:
>> On Tue, 17 May 2005 11:12:36 +0900, Mike Parker wrote:
> 
>> Ummmm... don't think it does have an opAssign. I wish it did! It would make my coding life a lot easier.
> 
> Until I read this post I was utterly convinced D does have an opAssign and I was sure I had used it in my code. Going back and reading the language reference and looking at the code in question, I was wrong on both counts. So why don't we have an opAssign?

I think its because Walter believes that the '=' symbol is ambiguous. It doesn't tell you if the value or the reference is being copied/assigned. And to overload this symbol would only cause bugs to happen if people didn't know this.

What would be good would be to have a symbol (operator) that could (must be?) be overloaded that only means assign-by-value regardless of whether the identifier is a built-in (native type), struct, array, or class object. Now that *would* be useful. Many people over the years have suggested that ":=" be used for this purpose. Walter is yet to agree with this idea.

-- 
Derek
Melbourne, Australia
18/05/2005 5:09:57 PM

"Mike Parker" <aldacron71@yahoo.com> wrote in message news:d6enuc$1htn$1@digitaldaemon.com...
> Derek Parnell wrote:
>> On Tue, 17 May 2005 11:12:36 +0900, Mike Parker wrote:
>
>> Ummmm... don't think it does have an opAssign. I wish it did! It would
>> make
>> my coding life a lot easier.
>
> Until I read this post I was utterly convinced D does have an opAssign and I was sure I had used it in my code. Going back and reading the language reference and looking at the code in question, I was wrong on both counts. So why don't we have an opAssign?

http://www.digitalmars.com/d/faq.html#assignmentoverloading

On Wed, 18 May 2005 09:59:20 -0400, Ben Hinkle wrote:

> "Mike Parker" <aldacron71@yahoo.com> wrote in message news:d6enuc$1htn$1@digitaldaemon.com...
>> Derek Parnell wrote:
>>> On Tue, 17 May 2005 11:12:36 +0900, Mike Parker wrote:
>>
>>> Ummmm... don't think it does have an opAssign. I wish it did! It would
>>> make
>>> my coding life a lot easier.
>>
>> Until I read this post I was utterly convinced D does have an opAssign and I was sure I had used it in my code. Going back and reading the language reference and looking at the code in question, I was wrong on both counts. So why don't we have an opAssign?
> 
> http://www.digitalmars.com/d/faq.html#assignmentoverloading

Yes I understand this, but I think that Walter has a case of myopia. He seems to assume that because he can't see any good reason then it also means that nobody else can either.

In any case, the concept of 'copy-by-value' is used by all programmers at some point and would be very useful to have an overloadable operator symbol that represented that operation. If you don't care to use the current '=' that's fine by me, but some other operator token is surely possible, no?

And copy-by-value is *not* the same as a bit copy as it could involve some data manipulation (read: conversion-cast).

I can imagine some class or struct in which this below is reasonable ...

  Foo a = new Foo;
  double x;

  a := "1234";   // Convert the string to a numeric value.
  . . .
  a := 34.56;   // Convert the floating point to Foo's internal format.

  x := a * 3;

-- 
Derek Parnell
Melbourne, Australia
19/05/2005 2:03:19 AM

> I think its because Walter believes that the '=' symbol is ambiguous. It
> doesn't tell you if the value or the reference is being copied/assigned.
> And to overload this symbol would only cause bugs to happen if people
> didn't know this. 

The source of the opEquals ambiguity comes from the ambiguity that instantiating a type sometimes creates an instance of that type and sometimes creates a reference to that type.

It seems to me that the best option would be to remove the ambiguity.

And the best way I can see to do this is to remove the definition that a class is always a reference and then add the explicit restriction (it's currently implicit) to not allow classes to be instantiated on the stack or as a structure member.

This boils down to requiring class instances to be defined, not as

	MyClass	cvar;   // is always a null reference

but instead as

	MyClass* cvar;	// always defaults to null

Everything else would behave the same.  Then, "=" is always a bit copy, the ambiguity is removed, and you can safely allow it to be overloaded.
Trying to do "*cvar1 = *cvar2" would result in a call to an undefined method unless that class had specifically had an operator= defined.

This would also fix a common confusion when first beginning (myself included) of the following:

	MyClass cvar;
	cvar.foo();	// segmentation fault

This is perfectly legal in C++ and so it's a natural thing to try when first learning D.

                                          Brian
                                 ( bcwhite@precidia.com )

-------------------------------------------------------------------------------
     It's not the days in your life, but the life in your days that counts.