June 19, 2005 Re: opSliceAssign? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Derek Parnell | > 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.
|
June 20, 2005 Re: opSliceAssign? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrew Fedoniouk | 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. |
June 20, 2005 Re: opSliceAssign? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Stewart Gordon | "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. |
Copyright © 1999-2021 by the D Language Foundation