RE: [sv-ac] P1800 SV-AC: vote on #1549

I think that the issue is that we introduce a new keyword "implicit" and
there is generally resistance to introducing new keywords that have a
very narrow usage, in this case only in the list of arguments to
properties and sequences. Therefore, either the other committees find it
useful in other contexts or we perhaps may have to retract it. In fact,
it is not obvious to me that we do really need it, because we could
require that all untyped arguments be placed first on the list.
 
Best regards
ed
 


________________________________

	From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
Of Lisa Piper
	Sent: Monday, September 11, 2006 11:05 AM
	To: Bassam Tabbara; sv-ac@eda.org
	Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549 
	
	

	 

	 

	
________________________________


	From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf
Of Bassam Tabbara
	Sent: Friday, September 08, 2006 1:54 PM
	To: sv-ac@eda.org
	Subject: RE: [sv-ac] P1800 SV-AC: vote on #1549 

	 

	I vote No. I think voting now is rushed -- we need take back to
committee for more discussions on the following:

	 

	a) Clarify how the new types should be handled in checking and
error reporting and also in relation to the "true nature" identification
functions that Dmitry proposed (isSequence() etc...). Currently it's not
clear at all what compiler *shall* vs. may vs. .... do if the type is
different than nature, and what the user expectation might be here ....
[Note the proposal currently has a bunch of "may be's" that bug me.]

	[Lisa Piper >>>] I did a search and see 3 "may ..." and those
statements say that <things> "may" be typed.  They might also be untyped
in which case no type checking will occur.    Is this what you are
referring to? 

	 

	How the "new types" should be handled in checking and error
reporting is a generic issue that applies to all types in all functions,
tasks, classes etc?  Do you see some conflict with Dmitry's proposal?   

	b) "implicit" as we discussed before is handy potentially for SV
in general, that said, it should probably be added elsewhere (with other
types/qualifiers) and referenced here. So we should check with other
committees to find the best way to handle this (incl. double-check on an
existing/better way even) rather than add it exclusively here.

	[Lisa Piper >>>] does using it here prevent it from being used
elsewhere?

	 

	Thx.

	-Bassam.