TechnoZeus wrote:
> Nice summary.  Thanks.
> 
> Two points I would like to bring up....
> 
> First, is that value types do have an identity.  Even a litteral has an identity, because it has to be stored "somewhere" to be used. Therefore, it may be "possible" but undesireable to allow identity assignemnts to value types in general.  In cases where it is desireable, pointers would suffice.  Not an argument for or against anything you said... just a detail that I thought should be mentioned.
> 
> Second, is that while I think adding ":=" as a value assignemt operator would be a great idea, I also think that making "=" into something that it's not would be a very bad idea.  If there is to be a "reference assignment" operator, I think it should be something that is not currently in use.
> 
> In other words, as messy as it is, I would say leave the "=" operator have it's current quirks, for backward compatibility if nothing else, but add ":=" for value assignments, and add an identity assignment operator so that explicit identity assignments or would be possible without having to resort to using value assignments on pointer types and without having to use the "=" operator if the programmer chooses to avoid it.  This way, perhaps a compiler switch could even be added that would warn on the use of the "=" operator, so that people who have found it to be involved in the production of too many bugs could phase it out if they so choose.
> 
> Also, I would personally recommend that the following two default members be supported on everything that is capable of supporting them:  ".value" to explicitly access or assign the item's value, and ".identity" to explicitly access or assign the item's identity.
> 
> Most important though of all that's been mentioned in this thread, in my opinion, would be the addition of a ":=" value assigment operator.  (Perhaps =:= could be added also as an explicit value comparison operator.  Also, >:= and <:= and so on, as well as the natural extension to +:= and -:= and so on for explicit "modify and assign value" operators.  Just a thought.)
> 
> TZ
I think we should campaign for ":=" right now.  I don't think we need a special "identity assignment" operator just yet - but I am fully infavour of the ".value" and ".address" properties for all types.  If people find they are typing "x.address = y.address" on a regular basis, then we would have a case for an address assignment operator.

Walter - what do you think of this discussion?

Cheers
Brad

Yes, I agree fully.

Walter?  Could we please have a ":=" value assignment opperator, that assigns values by default and never assigns an address unless that address is actually the value of the item (such as the value of a pointer, for example)?

TZ

"brad beveridge" <brad@nowhere.com> wrote in message news:d458ge$2p8p$1@digitaldaemon.com...
> TechnoZeus wrote:
> > Nice summary.  Thanks.
> >
> > Two points I would like to bring up....
> >
> > First, is that value types do have an identity.  Even a litteral has an identity, because it has to be stored "somewhere" to be used. Therefore, it may be "possible" but undesireable to allow identity assignemnts to value types in general.  In cases where it is desireable, pointers would suffice.  Not an argument for or against anything you said... just a detail that I thought should be mentioned.
> >
> > Second, is that while I think adding ":=" as a value assignemt operator would be a great idea, I also think that making "=" into something that it's not would be a very bad idea.  If there is to be a "reference assignment" operator, I think it should be something that is not currently in use.
> >
> > In other words, as messy as it is, I would say leave the "=" operator have it's current quirks, for backward compatibility if nothing else, but add ":=" for value assignments, and add an identity assignment operator so that explicit identity assignments or would be possible without having to resort to using value assignments on pointer types and without having to use the "=" operator if the programmer chooses to avoid it.  This way, perhaps a compiler switch could even be added that would warn on the use of the "=" operator, so that people who have found it to be involved in the production of too many bugs could phase it out if they so choose.
> >
> > Also, I would personally recommend that the following two default members be supported on everything that is capable of supporting them:  ".value" to explicitly access or assign the item's value, and ".identity" to explicitly access or assign the item's identity.
> >
> > Most important though of all that's been mentioned in this thread, in my opinion, would be the addition of a ":=" value assigment operator.  (Perhaps =:= could be added also as an explicit value comparison operator.  Also, >:= and <:= and so on, as well as the natural extension to +:= and -:= and so on for explicit "modify and assign value" operators.  Just a thought.)
> >
> > TZ
> I think we should campaign for ":=" right now.  I don't think we need a special "identity assignment" operator just yet - but I am fully infavour of the ".value" and ".address" properties for all types.  If people find they are typing "x.address = y.address" on a regular basis, then we would have a case for an address assignment operator.
>
> Walter - what do you think of this discussion?
>
> Cheers
> Brad

On Wed, 20 Apr 2005 03:20:01 -0500, TechnoZeus <TechnoZeus@PeoplePC.com> wrote:
> Nice summary.  Thanks.
>
> Two points I would like to bring up....
>
> First, is that value types do have an identity.  Even a litteral has an identity, because it has to be stored "somewhere" to be used.

Agreed.

> Therefore, it may be "possible" but undesireable to allow identity assignemnts to value types in general.

Something like:

int a,b;
&a = &b;

This would effectively ignore the memory 'a' occupied and make 'a' and alias of 'b'.

> In cases where it is desireable, pointers would suffice.

Pointers are a piece of memory whose value is the address of a piece of memory. (I'm sure you know this.. I'm just leading in..)

They don't really facilitate identity assignment of value types, rather, they themselves have a fixed identity (the addres in which they are stored) and their value is the identity of something else (or themselves). You can assign to them another identiy, but this doesn't effect their identity, the identity of the value to which they are assigned or were previously assigned.

> Not an argument for or against anything you said... just a detail that I thought should be mentioned.

Splitting hairs is fun, often I find it asks you to look at something in a different light, usually increasing understanding of the subject overall.

> Second, is that while I think adding ":=" as a value assignemt operator would be a great idea, I also think that making "=" into something that it's not would be a very bad idea.  If there is to be a "reference assignment" operator, I think it should be something that is not currently in use.

"=" is currently a reference assignment operator (for reference types) and a value assignment operator (for value types). I wasn't suggesting that it change in any way. I can see, re-reading my post, how by labelling it a "reference assignment" I might have given an impression of change, but note the "exception" I spoke of and my conclusion:

<quote>
2. "="  does identity assignment
...
Exception to 2, a value type. You cannot assign identity to a value type, so you assign value (current D behaviour).

So, as you can see the exceptions are parallel, the behvaiour of "=" need not change, all that is added is ":=" and opAssign overloads for reference types.
</quote>

In short, leave it the same as it is currently.

> In other words, as messy as it is, I would say leave the "=" operator have it's current quirks, for backward compatibility if nothing else,

Yes.

> but add ":=" for value assignments,

Yes.

> and add an identity assignment operator so that explicit identity assignments or would be possible without having to resort to using value assignments on pointer types and without having to use the "=" operator if the programmer chooses to avoid it.

I don't see a point in this. All you're really doing is creating another name for an existing type, just like passing it into a function with "inout" does.

Currently you can achieve this by:
- passing it into a function using 'inout'.
- using "alias".

Personally I have never had the need to alias an existing type in this way. However, thinking about it...
If _anything_ I would suggest adding a referece type specifier, eg.

int  a;
int& b; //reference type, like C++ reference parameters to functions.

b = a;  //reference assignment, as 'b' is a reference type;
b = 5;  //assigns 'a' to 5
assert(a == b);

this would have the syntax of a value type, but be a reference to some other value type elsewhere.

Note, the "=" operator does not change in any way and no explicit identity assignment operator is required.

However, if these were added then "is" would need to change to handle "if (b is a)" i.e. is "b" a reference to "a", luckily the LHS is a reference type, so this might not be too hard to manage.

> Also, I would personally recommend that the following two default members be supported on everything that is capable of supporting them:  ".value" to explicitly access or assign the item's value, and ".identity" to explicitly access or assign the item's identity.

Assuming:
 - there is little need to assign identity for value types.
 - we have methods to do so, inout, alias.
   or we add a reference type for value types.

then I see no point in this.

> Most important though of all that's been mentioned in this thread, in my opinion, would be the addition of a ":=" value assigment operator.

Agreed.

> (Perhaps =:= could be added also as an explicit value comparison operator.  Also, >:= and <:= and so on, as well as the natural extension to +:= and -:= and so on for explicit "modify and assign value" operators.  Just a thought.)

I like how the current operators function. They already cover all the bases defaulting to the most sensible operation.

Regan


> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opspblnau423k2f5@nrage.netwin.co.nz...
>> On Sat, 16 Apr 2005 12:21:28 +0400, Vladimir <kv11111@mail.ru> wrote:
>> > Thanks a lot for good summary.
>> >
>> > Regan Heath wrote:
>> >> My take on "==" and "is" (for reference):
>> >>
>> >> 1. "==" does value comparison.
>> >> 2. "is" does identity comparison.
>> >>
>> >> Exception to 1, a reference type with no defined method of  
>> comparison is
>> >> compared using identity. If identity is equal, value will be equal.  
>> If
>> >> identity is not equal then given no way to compare value one must  
>> assume
>> >> inequality or throw an exception. (D assumes inequality, an exception
>> >> can
>> >> be thrown by coding it manually)
>> >>
>> >> Exception to 2, a value type. No 2 values types can compare equal in
>> >> identity. Technically this could be an error? However, D does a value
>> >> comparison. A lint program could catch and error on this. I see  
>> little
>> >> point and quite like the way "if (a is 5)" (where a is an 'int' or
>> >> similar) reads.
>>
>> > I thought that equality by identity means that if I change one of two
>> > equal objects, the second will be changed too.
>>
>> If they're objects (AKA references, AKA reference types), and you change
>> the "value", yes.
>>
>> > But know I understand that this is
>> > wrong for built-in types.
>>
>> But not for all built in types. "char[]" is a built in tpye, an array. It
>> is a "reference type".
>> "int" is a built in type. It is a "value type".
>>
>> > This could be another problem for general
>> > template programming.
>>
>> Agreed. I like having both value and reference types, they have thier
>> uses. Having the ability to restrict templates, and/or having
>> operators/methods with identical behaviour for both types of types solves
>> the template issues. I believe having a ":=" value assignment operator
>> helps.
>>
>> Regan
>
>

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 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.

May be just disallow of using '=' for built-in types and allow only ':=', but for classes allow both of them ?


>   - we have methods to do so, inout, alias.
>     or we add a reference type for value types.
alias is compile-time construction, isn't it ?

-- 
          Vladimir

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 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 "=".

>>   - we have methods to do so, inout, alias.
>>     or we add a reference type for value types.
> alias is compile-time construction, isn't it ?

True. "inout" is the only runtime one.

I'm still not convinced of the need to alias value types. However, assuming there is a need I would use a "basic reference type" i.e. "int a; int& b;" (see my last post for more details).

Regan
Regan

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.

2. Or, adding a "basic reference type" i.e. "int& a" would allow you to have a matrix of them, and get identity assignment.

3. Of course, adding an identity assignment operator and allowing identity assignment for value types would also work (provided you used that operator).

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

I should have been more clear in what I stated about pointers.
What I meant was that the :=" operator should effect "their own" value
(which is the address of what they are pointing to)
rather than the value of the anything that they might be pointing to.
In other words, that the value assignment operator should do direct value assignemts.
No compromises.

I think a separate identity assignment operator would be overkill, but I had included mention of it for completeness.

The addition of ".value" and ".identity" support would allow a way for programmers to avoid any ambiguity,
which would probably not get used a lot in the long run,
but would definately be nice to have as an option...
especially for beginners who are not sure of whether something is a value type or a reference type.
These members would allow them to treat "anything" as a value type,
or as a reference type (maybe it should be .reference rather than .identity?),
regardless of what it is...
and it would also be nice for searching the source code later.

As for +:= and so on... Not important at this time, but worth thinking about... in my opinion.

Hopefully when Walter has time to look in here, he'll give the ":=" value assignment operator strong consideration.
I don't know how he feels about bringing in programmers from different backgrounds,
but I think the addition of a ":=" assignment operator would be a good step in that direction,
due to people experienced in certain other languages finding it familliar and comfortable.

TZ

Not sure whether this would be advantageous or not,
but perhaps the "=" operator could be deprecated where it functions as a value assignment operator, so that it could be phased out in that capacity.

Okay... separate thread on a thought about deprecation, comming up.  :)

TZ


"Regan Heath" <regan@netwin.co.nz> wrote in message news:opspjwazw323k2f5@nrage.netwin.co.nz...
> 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.
>
> 2. Or, adding a "basic reference type" i.e. "int& a" would allow you to have a matrix of them, and get identity assignment.
>
> 3. Of course, adding an identity assignment operator and allowing identity assignment for value types would also work (provided you used that operator).
>
> 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

On Wed, 20 Apr 2005 17:44:15 -0500, TechnoZeus <TechnoZeus@PeoplePC.com> wrote:
> I should have been more clear in what I stated about pointers.
> What I meant was that the :=" operator should effect "their own" value
> (which is the address of what they are pointing to)
> rather than the value of the anything that they might be pointing to.

Just like "=" does currently.

> In other words, that the value assignment operator should do direct value assignemts.
> No compromises.
>
> I think a separate identity assignment operator would be overkill,
> but I had included mention of it for completeness.

Then we are in agreement, pretty much.

> The addition of ".value" and ".identity" support would allow a way for programmers to avoid any ambiguity,
> which would probably not get used a lot in the long run,
> but would definately be nice to have as an option...

Maybe, I'm not sold on the idea yet.

> especially for beginners who are not sure of whether something is a value type or a reference type.
> These members would allow them to treat "anything" as a value type,
> or as a reference type (maybe it should be .reference rather than .identity?),
> regardless of what it is...

But wouldn't this just train bad habits. Assuming using .value etc is only intended for beginners and you should really learn the difference between value and reference types.

> Hopefully when Walter has time to look in here, he'll give the ":=" value assignment operator strong consideration.

Fingers crossed.

Regan

Yes, for the most part, we are in agreement... is one of the things I was trying to clarify. (stating it outright does tend to help.)

As for letting beginners use ".value" and ".identity" to avoid ambiguity,
I wouldn't consider than enforcing bad habits, but rather discouraging them.

After all, their code would be practically self-documented in that sense.
Those of us who have already gotten used to the way things are would be the ones with
the bad habit of writing code that is harder for a person to be sure they understood correctly.
Given time,
most new programmers would also adapt the simpler way over the less ambiguous way,
but at least they would know that it's there in the event they're ever in doubt...
or just want to write more readable code.  :)

TZ


"Regan Heath" <regan@netwin.co.nz> wrote in message news:opspjzn4ky23k2f5@nrage.netwin.co.nz...
> On Wed, 20 Apr 2005 17:44:15 -0500, TechnoZeus <TechnoZeus@PeoplePC.com> wrote:
> > I should have been more clear in what I stated about pointers.
> > What I meant was that the :=" operator should effect "their own" value
> > (which is the address of what they are pointing to)
> > rather than the value of the anything that they might be pointing to.
>
> Just like "=" does currently.
>
> > In other words, that the value assignment operator should do direct
> > value assignemts.
> > No compromises.
> >
> > I think a separate identity assignment operator would be overkill, but I had included mention of it for completeness.
>
> Then we are in agreement, pretty much.
>
> > The addition of ".value" and ".identity" support would allow a way for
> > programmers to avoid any ambiguity,
> > which would probably not get used a lot in the long run,
> > but would definately be nice to have as an option...
>
> Maybe, I'm not sold on the idea yet.
>
> > especially for beginners who are not sure of whether something is a
> > value type or a reference type.
> > These members would allow them to treat "anything" as a value type,
> > or as a reference type (maybe it should be .reference rather than
> > .identity?),
> > regardless of what it is...
>
> But wouldn't this just train bad habits. Assuming using .value etc is only intended for beginners and you should really learn the difference between value and reference types.
>
> > Hopefully when Walter has time to look in here, he'll give the ":=" value assignment operator strong consideration.
>
> Fingers crossed.
>
> Regan