xs0 wrote:
>> Of course not, here it's obvious that I'm changing the contents of an already allocated piece of memory.  Just like it is when I use [] to force in-place assignment.
> 
> 
> Well, I should've written {{ int a; int *b=&a; a=2+3; }} and b still points to a.. But anyhow, we now seem to agree that there are issues, so let's leave = alone :)
....
> Well, if all you do is a=b, it will still work with arrays, although if that's really all you do, it shouldn't be an issue?
> 
> Of course, there's also op=. Which one should it be ( op= or op<== ), assuming not both get supported (which will probably not happen.. think about <=<== or >>><== or !<>=<== :)? I'd vote for <==, as op= does mean in-place in the case where it is normally used (i.e. primitives).
> 
> To further improve templating it might also make sense to extend .dup to value-based types (to handle cases where you do want copies made). 

What if we had an assignment operator that forces copy?

That would certainly stand out better in the code than a .dup
hidden somewhere in a long expression. (I know that mentioning
this probably causes a riot (if anyone else is actually still
reading this thread)), so the case would have to be really
strong. Is it?

> Unlike most other properties, it does make sense on all types - it says I want a copy. On primitive types and structs, .dup would just be their value itself (and that is their copy already). Classes can also implement .dup to return their clone. This only leaves a slight inefficiency when you do something like {{ a=(b+c*d).dup }} with classes, but when this becomes an issue, you can handle all class types with a single template specialization for Object.
> 
> 
> With all that, .minIdx, .maxIdx, .sum and .count and decent compiler support, some really neat things could be done, effective both in amount of code needed and resulting speed.
> 
> 
> xs0

Stewart Gordon wrote:
> xs0 wrote:
> <snip>
> 
>> And I'd guess that only the outer array gets reused with a[]=x+y? So what would you have the user type then? a[][][]=x+y? That's probably not even legal.. And what if a is of type T as in template(T)?
> 
> 
> Just thinking about this, at the moment we don't seem to have a means of deep in-place copying of nested dynamic arrays.  If we're going to support deep in-place assignment when doing arithmetic, we should have a corresponding means of simply copying an array in this way.  And so I guess the syntax would correspond.
<snip>

Just thinking about it again.  Is it really worth having deep in-place assignment, whether doing arithmetic or simple copying?  Or might it just as well wait until we get true multidimensional arrays?

Stewart.

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