> Foo a = new Foo();
> Foo b = new Foo();
> Bar c = new Bar();
> a := b; // calls Foo.opAssign(Foo rhs);
> a := c; // calls Foo.opAssign(Bar rhs);
>
> Also, array.dup can now go away.

array.dup would still be needed (like any dup property) in expressions that don't have any assignment. For example "return array.dup;"

>> > There are obviously advantages to adding a := operator for value assignments, and I have yet to hear a down side to it.
>>
>> http://www.digitalmars.com/d/faq.html#assignmentoverloading
>
> Why the link to information about assignment overloading?

That's what this discussion on := and opAssign are about. Walter has already thought about overloading assignment and it has come up before on the newsgroup (I actually found that link during a quick search of the archives).

In article <d46v3g$1n7o$1@digitaldaemon.com>, Ben Hinkle says...
>
>About the template problem: I'd prefer to look into something like extending ".dup" to all types rather than invent a new operator.

Ben, thank you.  You took the words right out of my mouth. :)

For classes, there's no need to make this a formal 'operator'.  It could merely be added to Object as a shallow copy (return this;) and then overridden in any class where it's needed.

So really, all that's needed is a 'dup' property for scalars.  The rest is up to the developer.


class Foobar{
public Foobar dup(){
return this; // or a copy
}
}

void main(){
Foobar a,b;
a = new Foobar();
b = a.dup; // custom ('deep') copy

int c,d;
c = d.dup; // value-copy: allowed for consistency

int[] e,f
e = f.dup; // old hat
}

The above folds into templates, extremely well:

template valueOf(T){ T valueOf(T x){ return x.dup; } }

.. where 'T' can be, well, anything.  I'll add that the above is also *impossible* with ':=' and would require a temporary varible to work.  Thus, it would be less flexible (and probably useful IMO).

There's absolutely no need for an additional operator like ':='.

- EricAnderton at yahoo

Ben Hinkle wrote:

>>> > There are obviously advantages to adding a := operator for value assignments, and I have yet to hear a down side to it.
>>>
>>> http://www.digitalmars.com/d/faq.html#assignmentoverloading
>>
>> Why the link to information about assignment overloading?
> 
> That's what this discussion on := and opAssign are about. Walter has already thought about overloading assignment and it has come up before on the newsgroup (I actually found that link during a quick search of the archives).
This discussion is not about opAssign overloading, but about problems when writing general templates that must work with classes as well as with fundamental types.

Addition of := operator may require making it overloadable because of external resource allocation (not only memory allocation but also opened files, DB connections and so on).

Allowing := overloading also will solve casting problem (for example ability to write BigInt class in such way that code { BigInt i; i:=100; } can be compiled), but this is just side-effect.

But again, even adding this operator will not solve the whole problem with general templates.


-- 
          Vladimir

Vladimir wrote:

> /* Class for calculation some difficult function and caching result */
> /* Suppose reverse function is easy to calculate */
> class SomeFunction(T) {
>         T _cached_val;
> 
>         T calculate(T input) {
>                 /* if T is class we have seg-v here at first invocation
>                  * because _cached_val is null */
>                 if(input == calculate_reverse(_cached_val))
>
> 2. reference-type variable are always initialized to null, while
value-type can't be null

One of possible solutions for this is to add static init property for classes:

class A {
        /* example */
        static A init = new A(0,0);  /* evaluated only once */

        /* default is: static A init = null; } */
}

and then treat expression
A a; as A a = A.init;
(this is exactly the same as with fundamental types)

so
A a; A b;
if((a is b) and (a is A.init)) writef(" true ");
will print "true"

-- 
          Vladimir

pragma wrote:

> In article <d46v3g$1n7o$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>About the template problem: I'd prefer to look into something like extending ".dup" to all types rather than invent a new operator.
> 
> Ben, thank you.  You took the words right out of my mouth. :)
> 
> For classes, there's no need to make this a formal 'operator'.  It could merely be added to Object as a shallow copy (return this;) and then overridden in any class where it's needed.
> 
> So really, all that's needed is a 'dup' property for scalars.  The rest is up to the developer.
> 
> 
> class Foobar{
> public Foobar dup(){
> return this; // or a copy
> }
> }
> 
> void main(){
> Foobar a,b;
> a = new Foobar();
> b = a.dup; // custom ('deep') copy
> 
> int c,d;
> c = d.dup; // value-copy: allowed for consistency
> 
> int[] e,f
> e = f.dup; // old hat
> }
> 
> The above folds into templates, extremely well:
> 
> template valueOf(T){ T valueOf(T x){ return x.dup; } }
> 
> .. where 'T' can be, well, anything.  I'll add that the above is also *impossible* with ':=' and would require a temporary varible to work. Thus, it would be less flexible (and probably useful IMO).
> 
> There's absolutely no need for an additional operator like ':='.
Formally you are right, but always typing a=b.dup is not convenient and can
be forgotten, especially when one tries to convert non-template function to
template.
May be we can add ':' unary operator which in expression :a works exactly
like a.dup ? So a=b.dup will look as a = :b or even a =: b. When returning
from function this will look like { return :a; }.

-- 
          Vladimir

In article <d48gt8$8ao$1@digitaldaemon.com>, Vladimir says...
>
>May be we can add ':' unary operator which in expression :a works exactly like a.dup ? So a=b.dup will look as a = :b or even a =: b. When returning from function this will look like { return :a; }.

The only wart here is that you'll run into small problems with ':' when evaluating the ternary '?' operator:

foo() ? bar() : a; // what was meant here?  (value-of or ternary else)

.. but that's strictly a matter of operator precedence.  I for one, don't find it as readable.

Not that I think it's a good idea, but you could use something like '@' to mean 'value-of' (which would be akin to '&' meaning 'address-of').

{ return @a; }

This isn't too bad, but it still lands us in "create a new operator territory".


I still think .dup() is the way to go.

-EricAnderton at yahoo

It's a big thread... that might have been in it somewhere.
This branch of it deals with adding ":=" as a separate operator in addition to the "=" operator,
and having ":=" act as a value assignment operator such that...
a := b;
anways results in (a == b) being true, but never makes (a is b) become true.

Not related to overloading the "=" operator.

TZ

"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d48dc2$54g$1@digitaldaemon.com...
> >> > There are obviously advantages to adding a := operator for value assignments, and I have yet to hear a down side to it.
> >>
> >> http://www.digitalmars.com/d/faq.html#assignmentoverloading
> >
> > Why the link to information about assignment overloading?
>
> That's what this discussion on := and opAssign are about. Walter has already thought about overloading assignment and it has come up before on the newsgroup (I actually found that link during a quick search of the archives).
>
>

"Vladimir" <kv11111@mail.ru> wrote in message news:d48gt8$8ao$1@digitaldaemon.com...
> pragma wrote:
>
> > In article <d46v3g$1n7o$1@digitaldaemon.com>, Ben Hinkle says...
> >>
> >>About the template problem: I'd prefer to look into something like extending ".dup" to all types rather than invent a new operator.
> >
> > Ben, thank you.  You took the words right out of my mouth. :)
> >
> > For classes, there's no need to make this a formal 'operator'.  It could merely be added to Object as a shallow copy (return this;) and then overridden in any class where it's needed.
> >
> > So really, all that's needed is a 'dup' property for scalars.  The rest is up to the developer.
> >
> >
> > class Foobar{
> > public Foobar dup(){
> > return this; // or a copy
> > }
> > }
> >
> > void main(){
> > Foobar a,b;
> > a = new Foobar();
> > b = a.dup; // custom ('deep') copy
> >
> > int c,d;
> > c = d.dup; // value-copy: allowed for consistency
> >
> > int[] e,f
> > e = f.dup; // old hat
> > }
> >
> > The above folds into templates, extremely well:
> >
> > template valueOf(T){ T valueOf(T x){ return x.dup; } }
> >
> > .. where 'T' can be, well, anything.  I'll add that the above is also *impossible* with ':=' and would require a temporary varible to work. Thus, it would be less flexible (and probably useful IMO).
> >
> > There's absolutely no need for an additional operator like ':='.
> Formally you are right, but always typing a=b.dup is not convenient and can
> be forgotten, especially when one tries to convert non-template function to
> template.
> May be we can add ':' unary operator which in expression :a works exactly
> like a.dup ? So a=b.dup will look as a = :b or even a =: b. When returning
> from function this will look like { return :a; }.
>
> -- 
>           Vladimir

Correct me if I'm mistaken, but I think what you are saying only takes reference types into account.  The idea here is to get away from the risk of code failing to work when value types and reference types inevitably get confused.

There is, for example, not much sense to the following code...

int a = 5.dup;
int b;
int c;
b = a.dup + 7.dup;
c = b.dup;

Of course, this is an extreme case, but it is meant to illustrate a point.

If the programmer wants to be sure that they are assigning values, and not changing the address of somehting, then the ":=" operator would be used...

int a := 5;
int b;
int c;
b := a+7;
c := b;

No ambiguity there.  Notice that with this convention, one would know what "a := b" is supposed to do, even without knowing what "a" and "b" represent.  The same can not be said of "a = b" in D.

TZ

"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d48iic$9se$1@digitaldaemon.com...
> It's a big thread... that might have been in it somewhere.
> This branch of it deals with adding ":=" as a separate operator in
> addition to the "=" operator,
> and having ":=" act as a value assignment operator such that...
> a := b;
> anways results in (a == b) being true, but never makes (a is b) become
> true.
>
> Not related to overloading the "=" operator.
>
> TZ

hehe. Sorry but it sounds funny to say an operator called := with overload opAssign is not related to overloading assignment. I would bet no matter what the symbol is and the overload name Walter's objections would still apply.

ps - I should have asked you to do my taxes :-)