Overloading of the assignment operator is not allowed in D.

But no problem, we can do it right now, in spite of it.

Just overload the opCatAssign operator instead, and use ~= where = would be used.

This way we might gather enough use cases to really know whether it is good or bad in practice.

The ~= looks peculiar enough to stick in the eye, and therefore the chances of mixups and misunderstandings are small. Since both writing the overloads and using the operator are exactly the same as with the "real" assignment operator overload, the lessons learned are immediately applicable if we later want to reconsider the omission of it.

Of course, I'm not suggesting using this in published code, or example code! But for "private" code, this may be an interesting addition to the mental toolbox.

I think it is quite unusual to concatenate two "free standing" objects. Concatenation is only used with strings, or to join objects to arrays, or two arrays to each other. Therefore using this operator (as a substitute for the regular assignment operator) in a non-array context should not bring too much of a mental strain for the reader.

---

One could use any binary operator here, but it is much simpler if the same one is used by all programmers.

Georg Wrede wrote:
> Overloading of the assignment operator is not allowed in D.

Overloading the assignment operator in a language where objects are manipulated through references would be a bit weird, wouldn't it?  It would almost require the creation of a new assignment operator meant specifically for copy semantics, similar to how we have '==' and 'is' for identity vs. equality comparisons.


Sean

Georg Wrede wrote:
> Overloading of the assignment operator is not allowed in D.
> 
> But no problem, we can do it right now, in spite of it.
> 
> Just overload the opCatAssign operator instead, and use ~= where = would be used.
> 
> This way we might gather enough use cases to really know whether it is good or bad in practice.
> 
> The ~= looks peculiar enough to stick in the eye, and therefore the chances of mixups and misunderstandings are small. Since both writing the overloads and using the operator are exactly the same as with the "real" assignment operator overload, the lessons learned are immediately applicable if we later want to reconsider the omission of it.
> 
> Of course, I'm not suggesting using this in published code, or example code! But for "private" code, this may be an interesting addition to the mental toolbox.
> 
> I think it is quite unusual to concatenate two "free standing" objects. Concatenation is only used with strings, or to join objects to arrays, or two arrays to each other. Therefore using this operator (as a substitute for the regular assignment operator) in a non-array context should not bring too much of a mental strain for the reader.
> 
> ---
> 
> One could use any binary operator here, but it is much simpler if the same one is used by all programmers.

I agree, I have been using =~ in some cases for assignment for close to a year now. Its decent, and it works. And as we were discussing on #D one day, its ironic that a decision made by walter designed to un-obfuscate code might end up causing developers to implement work-arounds like this, resulting in MORE obfuscated code......

go figure... :)

Georg Wrede wrote:
> Overloading of the assignment operator is not allowed in D.
> 
> But no problem, we can do it right now, in spite of it.
> 
> Just overload the opCatAssign operator instead, and use ~= where = would be used.
> 
> This way we might gather enough use cases to really know whether it is good or bad in practice.
<snip>

Why do you have to think in C++ when coding in D?

Hasan Aljudy wrote:
> Georg Wrede wrote:
> 
>> Overloading of the assignment operator is not allowed in D.
>>
>> But no problem, we can do it right now, in spite of it.
>>
>> Just overload the opCatAssign operator instead, and use ~= where = would be used.
>>
>> This way we might gather enough use cases to really know whether it is good or bad in practice.
> 
> <snip>
> 
> Why do you have to think in C++ when coding in D?

I don't. Do you?

Seriously, if you look back in the archives, I've been pretty voluminous in my support of several ideas and opinions. Getting assignment operator overload hasn't been one of them.

Then again, some other people have really wanted it, and I stumbled on a method to try it out with, which I wrote here. Now they can try it out, without Walter having to make changes to the language.

Georg Wrede wrote:
> Hasan Aljudy wrote:
> 
>> Georg Wrede wrote:
>>
>>> Overloading of the assignment operator is not allowed in D.
>>>
>>> But no problem, we can do it right now, in spite of it.
>>>
>>> Just overload the opCatAssign operator instead, and use ~= where = would be used.
>>>
>>> This way we might gather enough use cases to really know whether it is good or bad in practice.
>>
>>
>> <snip>
>>
>> Why do you have to think in C++ when coding in D?
> 
> <snip> Then again, some other people have really wanted it,
<snip>

so my point still stands.

On Thu, 14 Sep 2006 17:30:29 +0300, Georg Wrede wrote:

> Overloading of the assignment operator is not allowed in D.
> 
> But no problem, we can do it right now, in spite of it.

I'm happy to not have the assignment operator overloaded in D.

I'm unhappy that D doesn't have a copy operator. If it did, I'd like to overload that!

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
15/09/2006 11:25:23 AM

Derek Parnell wrote:
> On Thu, 14 Sep 2006 17:30:29 +0300, Georg Wrede wrote:
> 
>> Overloading of the assignment operator is not allowed in D.
>>
>> But no problem, we can do it right now, in spite of it.
> 
> I'm happy to not have the assignment operator overloaded in D.

For classes I agree. Overloading reference assignment doesn't make much sense. For structs on the other hand, assignment means (shallow) copying and being able to define that behavior would be useful.

> 
> I'm unhappy that D doesn't have a copy operator. If it did, I'd like to
> overload that!

But in a way it does have one such operator. I am thinking about []=.

struct Matrix {
	T* ptr;
	size_t w,h;
	...
	Matrix opSliceAssign(Matrix b) {...}
}

Matrix a,b;
...

a=b;   // Makes a refer to the same memory as b
a[]=b; // Copies the contents of b to a

/Oskar

On Fri, 15 Sep 2006 09:43:07 +0200, Oskar Linde wrote:

> Derek Parnell wrote:
>> On Thu, 14 Sep 2006 17:30:29 +0300, Georg Wrede wrote:
>> 
>>> Overloading of the assignment operator is not allowed in D.
>>>
>>> But no problem, we can do it right now, in spite of it.

>>  ...
>>
>> I'm unhappy that D doesn't have a copy operator. If it did, I'd like to overload that!
> 
> But in a way it does have one such operator. I am thinking about []=.
> 
> struct Matrix {
> 	T* ptr;
> 	size_t w,h;
> 	...
> 	Matrix opSliceAssign(Matrix b) {...}
> }
> 
> Matrix a,b;
> ...
> 
> a=b;   // Makes a refer to the same memory as b
> a[]=b; // Copies the contents of b to a

This is still a workaround though as it doesn't really work for arrays
(it's just a shallow copy and you can't overload it), and doesn't work for
scalars (bad syntax).

However, a new operator that can be used with all types and can be overloaded for structs, and classes would be a much better alternative, especially with generic coding (templates/mixins) in mind.

Hopefully Walter will 'see the light' and schedule this useful concept into v2 ;-)

-- 
Derek
(skype: derek.j.parnell)
Melbourne, Australia
"Down with mediocrity!"
15/09/2006 5:50:16 PM

Georg Wrede wrote:
> Hasan Aljudy wrote:
>> Georg Wrede wrote:
>>
>>> Overloading of the assignment operator is not allowed in D.
>>>
>>> But no problem, we can do it right now, in spite of it.
>>>
>>> Just overload the opCatAssign operator instead, and use ~= where = would be used.
>>>
>>> This way we might gather enough use cases to really know whether it is good or bad in practice.
>>
>> <snip>
>>
>> Why do you have to think in C++ when coding in D?
> 
> I don't. Do you?
> 
> Seriously, if you look back in the archives, I've been pretty voluminous in my support of several ideas and opinions. Getting assignment operator overload hasn't been one of them.
> 
> Then again, some other people have really wanted it, and I stumbled on a method to try it out with, which I wrote here. Now they can try it out, without Walter having to make changes to the language.

There is more to it than having an operator to overload. You want to be able to overload both assignment and copying.

Given

struct T { ... opCatAssign(T t) {...} }
void func(T t) {...}
T a,b;

You take care of

	a ~= b;

but not

	func(b);

where a copy is created too.

/Oskar