RE: [sv-ec] Re: [sv-bc] Musings on array assignment compatibility

Greg,

 

Regardless of which proposal modes forward, both the BC/EC committees
have agreed in principal that a simple array assignment requires
elements with equivalent types. So any proposal would clarify this rule,
removing existing contradictions.

 

The UAC proposal is just a clarification that element unraveling of
embedded arrays assigns each element using assignment compatibility
rules. Assignment patterns do not unravel elements of arrays. There is
no new functionality or new duplication here. It's just an informative
note that for single dimensional arrays, you can get the assignment
compatibility people are looking for when copying arrays simply by
enclosing the array in braces.

 

 

________________________________

From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] On
Behalf Of Greg Jaxon
Sent: Tuesday, June 02, 2009 10:16 PM
To: sv-bc@eda.org
Cc: sv-ec@eda.org
Subject: [sv-ec] Re: [sv-bc] Musings on array assignment compatibility

 

The Unpacked Array Concatenation (UAC) form requires an extensive
proposal whose details we have not seen,
and which probably duplicate features already provided by assignment
patterns to unpacked arrays. Please note
that in an assignment pattern the elements need only be assignment
compatible, so the compelling case of
unpacked array initialization is already covered adequately.

As I understood the 2611 proposal, all unpacked structure needed to be
conformable (same rank, same unpacked dimension lengths).
Only packed elements could be truncated or extended.

As much as I like the [=] [<=]  notation for elementwise assignment, it
does not cover function actual or assignment pattern
activities, so it is no substitute for the 2611 proposal.   Likewise for
foreach'().

The standard already encourages issuing a warning whenever an assignment
silently causes a truncation or extension.
Surely a more strident warning or a standard required warning could be
used to avoid users being blindsided by this extension.

Greg

Rich, Dave wrote: 

If the arrays do not have matching bounds and increments, and the
element types are not equivalent, I question the value of having a piece
of syntax that lets you blindly make an assignment from one array to
another.
 
I feel the UAC form covers the majority of cases, and the rest (like the
foreach'() cast) can be left for an enhancement in a future revision.
 
  

	-----Original Message-----
	From: Jonathan Bromley
	Sent: Tuesday, June 02, 2009 9:59 AM
	To: Rich, Dave
	Cc: sv-bc@server.eda.org; sv-ec@server.eda.org
	Subject: RE: [sv-bc] Musings on array assignment compatibility
	 
	Dave Rich wrote:
	 
	    

		BTW your examples are all packed arrays, not unpacked.
		      

	Ouch - that's embarrassing.  Thanks for pointing it out.
	Of course I intended them to be unpacked.
	 
	Thanks for the other comments too.  One specific response:
	 
	    

		int A[2][2];
		byte B[2][2];
		 
		Isn't the intent clearer to write as
		  foreach(A[i,j]) A[i][j] = B[i][j];
		rather than
		  $cast(A,B);
		      

	Definitely; but the problem is - and has always been -
	that this only works because you happen to know
	that all the dimensions have matching bounds and
	increments.  Given
	 
	  int A[1:2][1:0];
	  byte B[1:0][10:11];
	 
	things get much, much messier.  Of course it *can*
	be done, thanks to the query functions, but it's
	not pretty.  And I don't think there is any really
	general way for a user to code such a copy operation,
	except perhaps by some very creative use of macros.
	--
	Jonathan Bromley
	    

 
 
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
 
 
  

-- 
This message has been scanned for viruses and 
dangerous content by MailScanner <http://www.mailscanner.info/> , and is

believed to be clean. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.