> 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, I came up to the same dilemma:

Either opAssign either const. First one is more universal as
it allows to make a read-only/controllable wrapper - so to create synthetic
read-only-ness.

I think that it would be enough if only structs
will have opAssign/opSliceAssign as they are value types.
And I think that opAssign for classes makes no much sense.

To be "assignable" is a primordial characteristic of value type. And process of assignment must be controllable.

double d = 5; // compiler controls it and makes transoformation call.

Any ideas why it should be disabled for developers then?


Andrew.

Andrew Fedoniouk wrote:
<snip>
> I think that it would be enough if only structs
> will have opAssign/opSliceAssign as they are value types.

You mean opAssign should be allowed if the rvalue is of a different type?

And why should only structs have opSliceAssign?  It makes perfect sense in classes, just as opIndexAssign does.

> And I think that opAssign for classes makes no much sense.

Agreed.

> To be "assignable" is a primordial characteristic of value type.
> And process of assignment must be controllable.
> 
> double d = 5; // compiler controls it and makes transoformation call.

This isn't overloading the assignment operator, but an implicit type conversion.

> Any ideas why it should be disabled for developers then?

AIUI not allowing the programmer to define implicit type conversions was a conscious decision, since they can get quite complex, hard to implement and hard to understand.

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:d963gv$ju6$1@digitaldaemon.com...
> Andrew Fedoniouk wrote:
> <snip>
>> I think that it would be enough if only structs
>> will have opAssign/opSliceAssign as they are value types.
>
> You mean opAssign should be allowed if the rvalue is of a different type?

I think yes.

I can see overload of opAssign:

struct string
{
   wchar[] chars;
   bool      readonly;

   string opAssign( char[] cs ) {  }
   string opAssign( wchar[] cs ) {  }

}

as pretty handy.


>
> And why should only structs have opSliceAssign?  It makes perfect sense in classes, just as opIndexAssign does.

Agreed. My fault, thanks.

>
>> And I think that opAssign for classes makes no much sense.
>
> Agreed.
>
>> To be "assignable" is a primordial characteristic of value type. And process of assignment must be controllable.
>>
>> double d = 5; // compiler controls it and makes transoformation call.
>
> This isn't overloading the assignment operator, but an implicit type conversion.

Yes, I know. But idea is exactly the same, isn't it?

>
>> Any ideas why it should be disabled for developers then?
>
> AIUI not allowing the programmer to define implicit type conversions was a conscious decision, since they can get quite complex, hard to implement and hard to understand.

Agreed, programming is not a simple business
and sometimes type conversions are tricky.
E.g. I would like to disable implicit type conversion for
bool (bit) type in D. And I cannot.

One more: try to reproduce in D what I did in C++:
http://www.codeproject.com/cpp/value_t.asp
This is all about opAssign.

Andrew.