April 21, 2005
Yep... I totally agree.  Better to let "=" act as it does now, and let ":=" assign by copying the contents of the source item into the destination item.

As for the established mathematical identity operator, I would recommend that for identity comparisons, except that I've never seen a keyboard with that symbol on it.


TZ

"Brad Beveridge" <brad@somewhere.net> wrote in message news:d46t6k$1lja$1@digitaldaemon.com...
> Christian Schüler wrote:
> > Just as I was expecting that a google search on "mathematical identity" would turn up loads of examples, it fails on me...
> >
> > The proper symbol for identity is really U+2261, "identity", a = with 3 dashes.
> >
> > Besides that, I recall := being used in mathematical context for expressing identity as opposed to equal values, which is what = stands for.
> >
>  From a practical programmers point of view, I don't think that the
> operator we choose is particularly relevant.  I think that ":=" was
> adopted because it has the "=" sign in it, it looks like an assignment
> operation, and Pascal programmers will be familiar with it.
> I think it would be folly to try to use "=" for deep copy, and ":=" for
> what we currently use "=" for.
> Anyhow - the real core of the issue is that many of us feel a "deep
> copy" operator makes sense.
>
> Brad


April 21, 2005
"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d46tp4$1m37$1@digitaldaemon.com...
> I'm inviting anyone who wants to summarize their thoughts or comments on the proposed ":=" assignment opperator to do so as a reply to this post... to save Walter the time necessary to otherwise search for such comments.

What exactly is the proposed behavior? For instance what would it do for builtin types, pointers, arrays, structs, and classes? The post with [suggestion][Walter] in the subject mentions "assign by value" but that's too vague for me. For example how deep does the deep assignment go?

I haven't looked at all the other posts in the thread but I'd be surprised if this is really the right way to address the problem. Actually now that I think of it - what is the problem? I assume it's that inside templates "=" assigns by value for value types and by reference for reference types, correct? Plus I skimmed a post or two about a problem that there is an asymmetry between "==" and "is" and assignment (which only has "=").

About the template problem: I'd prefer to look into something like extending ".dup" to all types rather than invent a new operator. But I haven't thought about it really.

About the asymmetry problem: D is designed to be practical so while it would be nice to have symmetry I wouldn't consider that a goal.


April 21, 2005
> What exactly is the proposed behavior? For instance what would it do for builtin types, pointers, arrays, structs, and classes? The post with [suggestion][Walter] in the subject mentions "assign by value" but that's too vague for me. For example how deep does the deep assignment go?
> 

Built-in types will behave exactly as they do with ":=" as they currently do with "="

Arrays will have a new array created, with each new element created from the old array using the ":=" operator.

Structs will have ":=" called on each member they contain - or if this is too hard, they will need to define opAssign().

Reference types (ie classes) will need to define the operator function opAssign, and they can do what they like.
Classes may also define overloaded opAssign functions, which could potentially act as object conversion operators.

Brad
April 21, 2005
"Ben Hinkle" <ben.hinkle@gmail.com> wrote in message news:d46v3g$1n7o$1@digitaldaemon.com...
>
> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d46tp4$1m37$1@digitaldaemon.com...
> > I'm inviting anyone who wants to summarize their thoughts or comments on the proposed ":=" assignment opperator to do so as a reply to this post... to save Walter the time necessary to otherwise search for such comments.
>
> What exactly is the proposed behavior? For instance what would it do for builtin types, pointers, arrays, structs, and classes? The post with [suggestion][Walter] in the subject mentions "assign by value" but that's too vague for me. For example how deep does the deep assignment go?
>
> I haven't looked at all the other posts in the thread but I'd be surprised if this is really the right way to address the problem. Actually now that I think of it - what is the problem? I assume it's that inside templates "=" assigns by value for value types and by reference for reference types, correct? Plus I skimmed a post or two about a problem that there is an asymmetry between "==" and "is" and assignment (which only has "=").
>
> About the template problem: I'd prefer to look into something like extending ".dup" to all types rather than invent a new operator. But I haven't thought about it really.
>
> About the asymmetry problem: D is designed to be practical so while it would be nice to have symmetry I wouldn't consider that a goal.
>
>

My understanding of the overal concensus is that := would be used to copy the
contents of the source to the destination,
but not copy the address of the source and not alter the address of the destination.
Not everyone is in "full agreement" but this much does appear to be pretty consistantly agreed on.

I didn't want to say too much in the post with [Walter] in the subject,
because I thought it better if everyone had an equal opportunity to present their take on it,
since the agreement was obviously not total and across the board.

To answer your questions, here is my take on the aspects which you asked about...

For basic data types, := would set the vaue of the item's data.

For pointer types, := would set the location pointed to by the pointer's value.

For array types, := would set the contents of the destination array or of the specified subset of the array in the case of a slice as the destination.

In general, when you name an object, you specify the identity of that object by name.  That identity is represented internally by a memory address.  The := operator would not assign anything to that address, but would rather assign something to the contents pointed to by that address.

I hope this helps to clarify what was meant.

TechnoZeus



April 21, 2005
"Brad Beveridge" <brad@somewhere.net> wrote in message news:d46vid$1nec$1@digitaldaemon.com...
> > What exactly is the proposed behavior? For instance what would it do for builtin types, pointers, arrays, structs, and classes? The post with [suggestion][Walter] in the subject mentions "assign by value" but that's too vague for me. For example how deep does the deep assignment go?
> >
>
> Built-in types will behave exactly as they do with ":=" as they currently do with "="
>
> Arrays will have a new array created, with each new element created from the old array using the ":=" operator.
>
> Structs will have ":=" called on each member they contain - or if this is too hard, they will need to define opAssign().
>
> Reference types (ie classes) will need to define the operator function
> opAssign, and they can do what they like.
> Classes may also define overloaded opAssign functions, which could
> potentially act as object conversion operators.
>
> Brad

Thanks.  You explained that much better than I did.  :)

TZ


April 21, 2005
Regan Heath wrote:

> On Thu, 21 Apr 2005 09:36:30 +1200, Regan Heath <regan@netwin.co.nz> wrote:
>> On Wed, 20 Apr 2005 17:21:59 +0400, Vladimir <kv11111@mail.ru> wrote:
>>> Regan Heath wrote:
>>>>
>>>> Assuming:
>>>>   - there is little need to assign identity for value types.
>>> Yes, but suppose someone (for example with python background) after
>>> reading
>>> that '=' is identity assignment operator
> 
> If they read this, it was poorly written because it's untrue. (I did try to qualify my statement when I said that, didn't I?)
> 
>>> decided to implement some features
>>> relying on it, for example symmetric matrixes:
>>>
>>> for(i=0; i<10; i++)
>>>         for(j=0; j<i; j++)
>>>                 matrix[j][i] = matrix[i][j];
>>> ...
>>> matrix[1][2] = 10;
>>>
>>> If matrix is array of objects then we have matrix[1][2] = matrix[2][1] = 10, but it differs for built-in types.
>>
>> True.
>>
>>> May be just disallow of using '=' for built-in types and allow only
>>> ':=',
>>> but for classes allow both of them ?
>>
>> If your intention is to assign "value" then you'd use ":=" not "=".
> 
> Or, flipside, if your intention was to assign "identity"..
> 
> If your matrix contained value types it would not work, so...
> 
> 1. Currently you could use "int*" to achieve what you want.
But not in general templates. For classes type C* means pointer to reference (and I do not understand why we need both references and pointers for classes).

> 2. Or, adding a "basic reference type" i.e. "int& a" would allow you to have a matrix of them, and get identity assignment.
I think this is reasonable. For value-types T& will be reference type, but for classes C& makes no sense so we can make C& be the same type as C.

> 3. Of course, adding an identity assignment operator and allowing identity assignment for value types would also work (provided you used that operator).
This seems to be really hard to implement. Compiled languages have no
run-time symbol tables, they assigns address to variable at compile time,
and it can't be changed at run-time.

> As to what method is best.. I'm not sure. #2 and #3 are a lot of work (I expect). #3 is alien (at least to me, and probably other C/C++/Java programmers). Leaving #1, which is essentially not using a value type where a reference type is required.
> 
> Regan

In C++ there were value-type and reference-type for any class or built-in
type. In D we have only reference-type for classes and only value-type for
anything else (pointers are something else). Adding := operator will smooth
this asymmetry, but not remove it totally.
I can see at least these remaining problems:
1. absent reference-type for non-classes (discussed above).
2. reference-type variable are always initialized to null, while value-type
can't be null
3. different behavior of 'is' operator for value-type and reference-type.

To illustrate some of this:

/* 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))
                        /* if T is class then by returning _cached_val we allow caller
                         * to change it and hurt our presious cache */
                        return _cached_val;
                        /* if we have := we can write
                         * { R t := _chached_val; return t; }
                         * but it's ugly and slow if R is big value-type struct */

                /* if T is value-type it won't compile */
                if( _cached_val is null ) {}

                /* here we obviously need := */
                _cached_for = input;

                /* here we change caller's variable if T is class,
                 * and := can't solve out problem */
                input += 10;

                ...

                /* again we have problem here */
                return _cached_val;
        }

        T calculate_reverse(T input) {
                ...
        }
}

-- 
          Vladimir
April 21, 2005
Vladimir wrote:
<snip>

> To illustrate some of this:
<snip>

Vladimir - that is a fantastic example of the disconnect between reference types and value types, and how screwed up you could potentially get with templates.  You've also illustrated that the := operator doesn't really cut it in terms of making life better.
Can we come up with something that fixes this?

Brad
April 21, 2005
Define "better" in that context.

True, it wouldn't solve "all" problems, but then again, nothing ever will.

There are obviously advantages to adding a := operator for value assignments, and I have yet to hear a down side to it.

TZ

"brad beveridge" <brad@nowhere.com> wrote in message news:d47ro7$2lem$1@digitaldaemon.com...
> Vladimir wrote:
> <snip>
>
> > To illustrate some of this:
> <snip>
>
> Vladimir - that is a fantastic example of the disconnect between
> reference types and value types, and how screwed up you could
> potentially get with templates.  You've also illustrated that the :=
> operator doesn't really cut it in terms of making life better.
> Can we come up with something that fixes this?
>
> Brad


April 21, 2005
"TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d48b73$2m6$1@digitaldaemon.com...
> Define "better" in that context.
>
> True, it wouldn't solve "all" problems, but then again, nothing ever will.
>
> There are obviously advantages to adding a := operator for value assignments, and I have yet to hear a down side to it.
>
> TZ

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



April 21, 2005
"Ben Hinkle" <bhinkle@mathworks.com> wrote in message news:d48chi$48n$1@digitaldaemon.com...
>
> "TechnoZeus" <TechnoZeus@PeoplePC.com> wrote in message news:d48b73$2m6$1@digitaldaemon.com...
> > Define "better" in that context.
> >
> > True, it wouldn't solve "all" problems, but then again, nothing ever will.
> >
> > There are obviously advantages to adding a := operator for value assignments, and I have yet to hear a down side to it.
> >
> > TZ
>
> http://www.digitalmars.com/d/faq.html#assignmentoverloading
>
>
>

Hi Ben.

Why the link to information about assignment overloading?

TZ