Good language design strives for rules which are simple to check and enforce, especially if it doesn't impair the functionality. In this case you can always declare the arguments as const ref if you aren't writing to them, so the simpler rule does not restrict the available functionality.
Note that this is not just a matter of implementation. It also makes it easier for users to determine whether they are coding by the rules. With the simple rules, you just need to check whether the ref argument is const ref to know whether this is considered an assignment. Otherwise you might have to track down every subroutine that this subroutine calls and passes the ref argument to, to see whether it assigns to it. That could be a very arduous task.
From: Rich, Dave [mailto:Dave_Rich@mentor.com]
Sent: Tuesday, October 25, 2011 10:55 AM
To: Bresticker, Shalom; Steven Sharp; Daniel Mlynek
Cc: sv-bc@eda.org
Subject: RE: [sv-bc] variable driven by continous assignment and ref port
There could be a procedural write; therefore you have to assume there will be. Otherwise you would have to expand all nested subroutine calls that pass that argument by reference to check for a write.
Dave
Mentor Graphics
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Bresticker, Shalom
Sent: Tuesday, October 25, 2011 4:16 AM
To: Steven Sharp; Daniel Mlynek
Cc: sv-bc@eda.org
Subject: RE: [sv-bc] variable driven by continous assignment and ref port
Why would there be a procedural write if the subroutine contains no assignment to the ref argument?
Shalom
From: Steven Sharp [mailto:sharp@cadence.com]<mailto:[mailto:sharp@cadence.com]>
This analysis is possible because module port connections are part of the static hierarchy. On the other hand, ref arguments to tasks/functions are done procedurally at runtime. Therefore I think passing a variable as a non-const ref argument to a task/function should be considered a procedural write. If the subroutine isn't intended to write to the ref argument, then it should be declared a const ref.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 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.Received on Tue Oct 25 19:27:23 2011
This archive was generated by hypermail 2.1.8 : Tue Oct 25 2011 - 19:27:28 PDT