| System Verilog | |||||
| LRM Changes to Draft 5 | |||||
| On | |||||
| Status Legend: Open, Remove Note, Change, No Change | |||||
| ID | Committee | Section | Description | Status | Changes |
| LRM-258 | SV-EC | 3.11.4 | Fix cross-reference to dynamic cast (LRM-115/117 was done incorrectly) | Change | Section 3.11.4 |
| LRM-259 | SV-EC | 11.3 | Correct indentation and placement of comments on example (LRM-203 was missed) | Change | Section 11.3 |
| LRM-260 | SV-EC | Index | Add srandom, urandom, and urandom_range to index (LRM-128 was delayed until other index work done) | Change | Index |
| LRM-261 | SV-EC | 3.3.1 | Editor’s Note: Is “integral” synonymous with “singular“? Both
terms are used liberally throughout the LRM. Section 12 refers to “integral singular” in multiple places. The BNF only defines “singular” (A.2.2.1). It appears to me that they are the same. If so, then only one term should be used throughout the LRM and BNF. If these terms are different, then another section needs to be added here describing singular, and the BNF needs to be defined for “integral”. RESPONSE: No. integral is not synonymous with singular. However, an integral is also a singular, but not the other way around (a singular is not necessarily an integral). For example, an event is a singular but not an integral. The term integral singular is obviously redundant and can be replaced by integral since it alone denotes both. |
No Change | Section 3.3.1 |
| LRM-262 | SV-EC | 3.7 | Editor’s Note: This syntax ought to be in the
syntax excerpt in section 3.2, but I could not find it in the Annex A BNF RESPONSE: Editor’s note is Correct. Modify the BNF as shown below. Add to this section snippets from variable_declaration and data_type productions. Add chandle to data_type production. Merge singular_type into data_type (remove singular_type), and change associative dimension. As shown below: |
Change | Section 3.7 |
| Section A.2.2.1 Section A.2.5 | |||||
| LRM-263 | SV-EC | 3.8 | Editor’s Note: This syntax ought to be in the
syntax excerpt in section 3.2, but I could not find it in the Annex A BNF RESPONSE: Editor’s note is Correct. That syntax must be allowed by the variable_decl_assignment BNF production. Modify that production as shown below (optional variable_dimension). variable_decl_assignment ::= variable_identifier [ variable_dimension ] [ = constant_expression ] | variable_identifier [ ] = new [ constant_expression ] [ ( variable_identifier ) ] | class_identifier [ parameter_value_assignment ] = new [ ( list_of_arguments ) ] Then the syntax for this section is then included by variable_declaration. |
Change | Section 3.8 |
| Section A.2.4 | |||||
| LRM-264 | SV-EC | 3.11.4.1 | Editor’s Note: Would “prototype” be a better term that “syntax”,
since these methods are not part of the BNF? RESPONSE: Yes, absolutely. Replace “syntax” with “prototype” in these sections. |
Change | Section 3.11.4.1 Section 3.11.4.2 Section 3.11.4.3 Section 3.11.4.4 Section 3.11.4.5 Section 3.11.4.6 |
| LRM-265 | SV-BC | 3.12 | Editor’s Note: I deleted the clause “i.e. an X will be read as
0...”. It no longer makes sense after change LRM-108, which reversed the sentence from converting 4-state to 2-state into converting 2-state to 4-state. Reply: I agree with the editor's note. It can be removed |
No Change | Section 3.12 |
| LRM-266 | SV-BC/SV-EC | 3.14 | Editor’s Note: Should “singular_type” be included in the casting
type? In fact, “simple_type” is only used by the casting_type production. Can
“simple_type” be replaced with “singular_type”? RESPONSE: No. (see LRM-49) Singular should not become a BNF term. |
No Change | Section 3.14 |
| LRM-267 | SV-EC | 3.15 | Editor’s Note: The paragraph above is only definition of
“singular” that I could find, outside of the BNF. The term should be defined in its own subsection, probably in 3.3.x, and the BNF included in that definition. A reference to that defining subsection should then be added to the preceding paragraph. RESPONSE: The term singular could be defined in its own section, but it is not a BNF term (see LRM-266). However, a definition for singular does not belong in Section 3.3.x since a singular is not an integral type. The singular definition should be moved to a new Section 3.14 (before the Casting section). That will make singular an index item, thus, easier to find. |
Change | Section 3.14 Section 3.15 |
| LRM-268 | SV-EC | 4.6 | Editor’s Note: Is new[] an operator, method or function (it is
called a both function and an operator in the next subsection). RESPONSE: The keyword new is a built-in mechanism. In the context of a class, it is considered a method, which is function, and in the context of dynamic-arrays it is considered an operator. There is no contradiction. Since it is a keyword and its semantics are built-in, it can be described as either. |
No Change | Section 4.6 |
| LRM-269 | SV-EC | 5.7 | Editor’s Note: I feel the preceding paragraph is awkwardly and
ambiguously worded. Why is “wire” in quotes? Is this an indication that it is not referring to the wire keyword? Even it that is the intent, it is easy to assume that the specific keyword is intended, and therefore that only the wire data type can be aliased. I suggest striking the “or “wire” “, or replacing it with “or net”. The same sentence says the alias connection must be “compatible” and must be the “same type”. To me, those are two different things. In Verilog, wire and tri are compatible, but are they the same type?. In Verilog, wire and tri1 have compatibility rules when connected together so there is no error or warning (see section 12.3.10). Can they be aliased to each other? What if I alias two nets, both wire types of exactly the same size, but one is declared as signed (or is coerced to being signed by being connected to a signed port in the containing module) and the other wire is unsigned? RESPONSE: The term “or wire” should removed. That sentence should read: The nets connected with an alias statement must be type compatible, that is, they have to be of the same net-type. For example, it is illegal to connect a wand net to a wor net with an alias statement. |
Change | Section 5.7 |
| LRM-270 | SV-EC | 5.7 | Editor’s Note: The statement that implicit nets are assumed to
be scalar is not accurate. For a module instance, if an undeclared identifier
is also declared as a port of the containing module, then a net of the port
size is assumed. I changed the wording as shown above. RESPONSE: The new wording is correct. |
No Change | Section 5.7 |
| LRM-271 | SV-EC | 6.1 | Editor’s Note: What other new SV objects can have attributes?
(program blocks, assertions, ...)? I will update the BNF syntax excerpt once
that has been determined. Will additional text for these other objects need
to be added in this section? I suggest this entire section is not needed. The BNF for each new SV object shows where attributes are legal, and does not need to be covered in a special section. The only change to the attribute construct itself in SystemVerilog 3.0 is the default data type of bit. Verilog-2001 says the default value is 1 (true). Is it necessary for SystemVerilog to specify the data type of that value in order for attributes to work with SystemVerilog constructs? If not, then let the IEEE determine the appropriate default data type, the IEEE sees a need for one. Response: The Syntax 6-1 is superflous and is removed. The section is renamed to Default attribute type and the text changed to support this. The default type was part of 3.0 and it is not possible to change this at this date. |
Change | Section 6.1 Section 6.2 |
| LRM-272 | SV-BC | 7.3 | Editor’s Note: Does the BNF reflect the preceding restrictions?
For example (if I am not mistaken) the current BNF can have @(expression),
which will allow @(a = b | c) (the example deleted with draft 5 from section
8.11). Response: This is a simple sematic restriction.
I am not in favor of splitting the expression BNF to represent this
restriction. The editor's not can be removed |
No Change | Section 7.3 |
| LRM-273 | SV-BC | 7.10 | Editor’s Note: Is the note above needed? It came from the old Superlog LRM, and was intended to show that Superlog used Verilog’s precedence instead of C’s. The SV LRM’s purpose is to show where SV operators fall with respect to Verilog operaotrs. Response: I agree with the editor's note. It along with the note can be removed | Change | Section 7.10 |
| LRM-274 | SV-BC | 7.11 | Editor’s Note: “bits” is not a keyword so I removed the bold-courier font. A concatenation can be used with reg, wire and many other data types. Since that is standard Verilog, I deleted the reference to just the logic data type. Response: I agree with the editor's note. It can be removed | No Change | Section 7.11 |
| LRM-275 | SV-EC | 7.11 | Editor’s Note: Does the BNF reflect this special case that for a string a non-constant replication multiplier is allowed? RESPONSE: It is in A.8.1 | No Change | Section 7.11 |
| LRM-276 | SV-EC | 8.7 | Editor’s Note: This seems out of place in this
section on procedural statements. It should be moved to section 9.9. RESPONSE: The editor’s note is an interesting comment. The final block is a statement, but it does not create a process (as intial and always blocks do). Therefore, it would seem appropriate to leave “final block” in the Section on “Procedural Statements and Control Flow”. Unfortunately there is a statement in 9.1 that discusses final blocks that must be moved to Section 8.1 or elase it does not make sense. Add clarification after discussion with Stu. |
Change | Section 8.1 Section 8.7 |
| Section 9.1 | |||||
| LRM-277 | SV-EC | 8.10 | Editor’s Note: What is meant by “This can be made clearer by the
use of parenthesis”? An example is needed. The BNF does not show optional
parentheses for iff. SystemSim does not allow the following: “always @(
(posedge clk iff !reset) or negedge reset)”. I wish it did--the extra
parenthesis does make it clearer what is being qualified by the iff. RESPONSE: That sentence means parenthesis can be used around the iff expression, which is allowed by the BNF. Using the same example as in the LRM: always @(a iff (enable == 1) ) |
No Change | Section 8.10 |
| LRM-278 | SV-BC | 9.5 | Editor’s Note: The preceding paragraph did not match the revised rules in 5.6. I made the changes shown above to make the tow sections match. Response: I agree with the editor's note. It can be removed | No Change | Section 9.5 |
| LRM-279 | SV-EC | 11.21 | Editor’s Note: Replace preceding syntax with
final BNF excerpt, once available. RESPONSE: Editor’s note is correct. This BNF entry should be added to the primary production: primary ::= … class_identifier :: {class_identifier ::} identifier |
Change | Section 11.21 |
| Section A.8.4 | |||||
| LRM-280 | SV-EC | 12.3 | Editor’s Note: I could not find this syntax in
the BNF. RESPONSE: Propose breaking up class_item into class_property , class_methods, and class_constraint, as shown below. |
Change | Section 12.3 |
| Section A.1.8 Section A.notes | |||||
| LRM-281 | SV-EC | 12.11.3 | Editor’s Note: Is “void = “ legal? See Section 10.3.2 Response: Editor is correct. That is not legal syntax. Example should be changed from: | Change | Section 12.11.3 |
| LRM-282 | SV-EC | 13.2.1 | Editor’s Note: Would “prototype” be a better term that “syntax”,
since methods are not part of the BNF? RESPONSE: Yes, absolutely. Replace “syntax” with “prototype” in these sections and for 13.3.1 sections. |
Change | Section 13.2.1 Section 13.2.2 Section 13.2.3 Section 13.2.4 Section 13.3.1 Section 13.3.2 Section 13.3.3 Section 13.3.4 Section 13.3.5 Section 13.3.6 Section 13.3.7 Section 13.3.8 |
| LRM-283 | SV-EC | 15.11 | Editor’s Note: I was not able to match the first
version of the original syntax with what is in the BNF. Nor does the BNF seem
to support example 2, below. RESPONSE: Editor is correct. The following should be added at the end of the module_or_generate_item_declaration BNF production (in A.1.5): module_or_generate_item_declaration ::= … default clocking clocking_identifier ; |
Change | Section 15.11 |
| Section A.1.5 | |||||
| LRM-284 | SV-EC | 15.14 | Editor’s Note: I could not find this syntax in
the BNF. RESPONSE: Add to statement_item (section A.6.4 page 295) the following: |
Change | Section 15.14 |
| Section A.6.4 Section A.6.11 | |||||
| LRM-285 | SV-AC | 17.4.1 | Editor’s Note: If I understand correctly from reading the BNF
and sections 3.3.2 and 3.15, “singular” does not include unpacked values.
Also, why isn’t time considered an integer (or singular) type? Response: The text should be corrected as below Any singular type is allowed, signed or unsigned, packed or unpacked, with the exception of event and the non-integer types time, shortreal, real, and realtime. The following types are non allowed: • non-integer_types ( time, shortreal, real and realtime) • string • event • chandle • class • associative arrays • dynamic arrays |
Change | Section 17.4.1 |
| LRM-286 | SV-AC | 17.7.2 | Editor’s Note: The preceding example description says “the following two examples...”, but it seems to be 1 example that expands to more than two possible matching sequences. Saying “two examples” does not seem to match the example. Response: The paragraph correctly says “ the following two expressions…”. Adding an empty line between the two expressions will distinguish the two expressions, as shown below: Same down for following example | Change | Section 17.7.2 |
| LRM-287 | SV-AC | 17.7.2 | Editor’s Note: I assumed that “should” was an indication of a mandatory requirement, though it could have meant an optional requirement. Response: That is correct. | No Change | Section 17.7.2 |
| LRM-288 | SV-AC | 17.12 | Editor’s Note: The 5 preceding syntax lines do not follow the
BNF format from Annex A. Should they be rewritten using the actual BNF? Are
these 5 syntax lines even needed, since the BNF is already included in this
subsection. Response: Should be corrected as
below: cover property ( [ clocking_event ] sequence_instance sequence_spec) statement_or_null or cover property ( [ clocking_event ] sequence_expr ) statement_or_null, or For property coverage, the statement appears as: All other forms of the cover statement are evaluated for property coverage. cover property ( property_instance ) statement_or_null or cover property ( [ clocking_event ] property_modifier property_expr) statement_or_null or cover property ( [ clocking_event ] property_implication) statement_or_null |
Change | Section 17.12 |
| LRM-289 | SV-AC | 17.12 | Editor’s Note: What is “attemptID”? It does not appear in the
BNF or the 5 syntax lines above. Response: attemptID
should be defined before use as below: The identifier of a particular attempt is called attemptId, and the clock tick of the occurrence of the match is called clock step. The results of coverage statement for a property shall contain: — Number of times attempted — Number of times succeeded — Number of times failed — Number of times succeeded because of vacuity — Each attempt with an identifier (attemptID) and time — Each success/failure with an identifier (attemptID) and time In addition, statement_or_null is executed every time a property succeeds. Vacuity rules are applied only when implication operator is used. A property succeeds non-vacuously only if the consequent of the implication contributes to the success. Results of coverage for a sequence shall include: — Number of times attempted — Number of times matched (each attempt can generate multiple matches) — Each attempt with attemptId and time — Each match with clock step, attemptID, and time In addition, statement_or_null gets executed for every match. If there are multiple matches at the same time, the statement gets executed multiple times, one for each match. attemptID is the identification of a particular attempt. Clock step is the clock tick of the occurrence of the match. |
Change | Section 17.12 |
| LRM-290 | SV-AC | 17.12.1 | Editor’s Note: The 4 preceding syntax lines do not follow the
BNF format from Annex A. Should they be rewritten using the actual BNF? Reply: No. The syntax lines are not BNF items and are
correct, but they can be made clearer as shown below: A concurrent assertion statement can be used directly outside of a procedural context. It can be used within a module as a module_common_item, an interface as a module_common_item, or a program as a non_port_item. In a module, it is used as a module_item and in an interface as an interface_item. A concurrent assertion statement is either an assert or a cover statement. Such a concurrent assertion statement uses the always semantics. The following two forms are equivalent: assert property ( property_spec property_spec) action_block action_block Accellera always assert property (property_spec property_spec) action_block action_block; Similarly, the following two forms are equivalent: cover property (property_spec property_spec) statement_or_null statement_or_null always cover property (property_spec property_spec) statement_or_null statement_or_null |
Change | Section 17.12.1 |
| LRM-291 | SV-BC | 19.2 | Editor’s Note: This declaration is greatly generalized from the
full BNF, but looks like it is the BNF. Is that a problem? Response: REPLACE the BNF style example interface <identifier>; <interface_items> endinterface [: <name> <identifier>] WITH something that looks more like an example *interface *<identifier>; <interface_items> *endinterface *[: <identifier>] |
Change | Section 19.2 |
| LRM-292 | SV-BC | 19.2.1 | Editor’s Note: Does “data” also need to change from logic to
wire in the top module? Response: In module top;
REPLACE logic [7:0] addr, data; WITH logic [7:0] addr; wire [7:0] data; |
Change | Section 19.2.1 |
| LRM-293 | SV-EC | A.1.8 | Editor’s Note: Unmatched sets of curly-braces on preceding line
(need to fix here and in section 12.4) RESPONSE: Replace the entire section A.1.8 with the contents of LRM-280, and the following new section (A.1.9). This production assumes that LRM-296 and LRM-280 have been applied. |
Change | Section A.1.8 Section A.1.9 |
| LRM-294 | SV-EC | A.1.8 | Editor’s Note: I am confused by the “constraint_item” and “constraint_item_or_block” productions. The seem to only refer to each other in a circular fashion. RESPONSE: Replace the entire section A.1.8 with the contents of LRM-280, and the following new section (A.1.9). This production assumes that LRM-296 and LRM-280 have been applied. | Change | Section A.1.8 Section A.1.9 |
| LRM-295 | SV-BC | A.6.2 | Editor’s Note: These production names are not consistent;, e.g. “always_construct” vs. “combinational_statement”. I suggest that all these procedures be referred to as “_construct”. | Change | Section A.1.5 Section A.1.6 Section A.6.2 |
| LRM-296 | SV-BC/SV-EC | A.8.6 | Editor’s Note: This section does not list all the operators
found in section 7.9, table 7-2. Should it?. RESPONSE: No additional operators need to be listed in this section. The missing operators (inside, dist, =>, := , :/ ) are handled by syntax alone (either constraints grammar or the inside rule). Nonetheless, the inside operator syntax is missing. Modify Section A.8.3, as shown (gray text is added) |
Change | Section A.8.3 Section A.8.6 |
| LRM-297 | SV-EC | C.5.15 | Editor’s Note: “assign” is a Verilog keyword. Is it a legal function name in this context? Response: No. It’s not allowed. The name of this method will change to set. | Change | Section C.3.2 Section C.5.15 |
| LRM-298 | SV-AC SV-BC SV-CC SV-EC | G | Editor’s Note: What additional terms should be added to this glossary? | Change | Section G |
| LRM-299 | SV-BC | 24.2 | Correct the string macro construction in 'define from earlier BC correction | Change | Section 24.2 |
| LRM-300 | SV-EC | 11.1 11.4 11.5 11.7 11.8 11.9 11.10 11.15 11.16 11.22 11.25 12.1 | Change to Chaper 11 per Arturo in response to Francoise comments. Includes changing type system to data abstraction, adding cross references, clarify types of class properties, reword new description, section name change, clarification of this and super, etc. | Change | Section 11.1 Section 11.4 Section 11.5 Section 11.7 Section 11.8 Section 11.9 Section 11.10 Section 11.15 Section 11.16 Section 11.22 Section 11.25 |
| Section 12.1 | |||||
| LRM-301 | SV-BC | B | Editor's Note: I forgot to add an editor note to draft 5, Annex
B. The keyword "edge" was
added to the table (in draft 4, I believe) as being new in SystemVerilog. Actually, "edge" is already a reserved (and used) keyword in the IEEE 1364 standard. It was an errata that "edge" was not listed in the SV Annex B. Now the errata is that "edge" is flagged as an SV keyword. The correction is to remove the bolding and footnote flag from the keyword "edge". |
Change | LRM_Changes_B.html |
| LRM-302 | SV-AC | A.2.10 17.7.2 | Change *> to *-> operator per Surrendra | Change | Section A.2.10 |
| LRM-303 | SV-AC | 1 | Add statement about adding assertions to 3.1 per Surrendra | Change | Section 1 |
| LRM-304 | SV-BC | 8.5.2 | There is an error in the description of the for loop variable. It has to be automatic, otherwise it will not get initialized properly at the start of each loop. This also means it cannot be referenced hierarchically. From Dave Rich | Change | Section 8.5.2 |
| LRM-305 | SV-BC | 5.5 | Dynamic processes have been removed from SV. (replaced with a fork/join_none). Remove reference per Dave Rich. | Change | Section 5.5 |
| LRM-306 | SV-CC | 27.1.2 | Delete entire section: it is unnecessary, as terminology used in this section is the same as used in section 17. From Joao | Change | Section 27.1.2 |
| LRM-307 | SV-CC | 27.2.1 | Handle plurality per Joao | Change | Section 27.2.1 |
| LRM-308 | SV-CC | 27.2.2 | Replace entire contents of section with following text per Joao | Change | Section 27.2.2 |
| LRM-309 | SV-CC | 27.2.3 | Handle plurality per Joao | Change | Section 27.2.3 |
| LRM-310 | SV-CC | 27.2.4 | Handle plurality per Joao | Change | Section 27.2.4 |
| LRM-311 | SV-CC | 27.3.1 | In figure 27-1, replace word "property" with "assertion" and add note below figure per Joao | Change | Section 27.3.1 |
| LRM-312 | SV-CC | 27.3.1 | Clean up example per Joao | Change | Section 27.3.1 |
| LRM-313 | SV-CC | 27.3.1 | Remove note per Joao | Change | Section 27.3.1 |
| LRM-314 | SV-CC | 27.3.2 | Rename list per Joao | Change | Section 27.3.2 |
| LRM-315 | SV-CC | 27.3.2.1 | Clean up example per Joao | Change | Section 27.3.2.1 |
| LRM-316 | SV-CC | 27.3.2.1 | Reword paragraph per Joao | Change | Section 27.3.2.1 |
| LRM-317 | SV-CC | 27.3.2.2 | Reword paragraph per Joao | Change | Section 27.3.2.2 |
| LRM-318 | SV-CC | 27.4.2 | Change event to reason per Joao | Change | Section 27.4.2 |
| LRM-319 | SV-CC | 27.4.2 | Reword and add cross-references per Joao | Change | Section 27.4.2 |
| LRM-320 | SV-CC | 27.5.1 | Reword usage examples per Joao | Change | Section 27.5.1 |
| LRM-321 | SV-BC | 4.2 | Fix definition of packed and unpacked arrays per Dave | Change | Section 4.2 |
| LRM-322 | SV-EC | 14.1 | Clarification from Cliff processed by Arturo | Change | Section 14.1 |
| LRM-323 | SV-EC | 14.3 | Clarification of #1step from Cliff processed by Arturo | Change | Section 14.3 |
| LRM-324 | SV-EC | 15.3 | Clarification on skews from Cliff processed by Arturo | Change | Section 15.3 |
| LRM-325 | SV-EC | 15.4 | Clarification on concatenations from Cliff processed by Arturo | Change | Section 15.4 |
| LRM-326 | SV-EC | 15.10 | Reword example comment from Cliff processed by Arturo | Change | Section 15.10 |
| LRM-327 | SV | Ack | This is a reminder for Stu to add back in the 3.0 contributors to the acknowledgments | Change | Section Ack |
| LRM-328 | SV-CC | 26.1.2 | Replace sentence per Joao | Change | Section 26.1.2 |
| LRM-329 | SV-CC | 26.2 | Add new text per Joao | Change | Section 26.2 |
| LRM-330 | SV-CC | 26.3 | Replace text and examples per Joao | Change | Section 26.3 |
| LRM-331 | SV-CC | 26.4.6 | Reword per Joao | Change | Section 26.4.6 |
| LRM-332 | SV-CC | D.7.7 | Reword per Joao | Change | Section D.7.7 |
| LRM-333 | SV-CC | D.7.8 | Reword per Joao | Change | Section D.7.8 |
| LRM-334 | SV-CC | D.8.2 | Reword per Joao | Change | Section D.8.2 |
| LRM-335 | SV-CC | D.8.3 | Reword per Joao | Change | Section D.8.3 |
| LRM-336 | SV-CC | D.8.3 | Reword comment per Joao | Change | Section D.8.3 |
| LRM-337 | SV-CC | D.9.1.3 | Reword per Joao | Change | Section D.9.1.3 |
| LRM-338 | SV-CC | D.10.3.2 | Reword per Joao | Change | Section D.10.3.2 |
| LRM-339 | SV-CC | D.10.3.2 | Add unsigned to prototype per Joao | Change | Section D.10.3.2 |
| LRM-340 | SV-CC | E.1 | Rework per Joao | Change | Section E.1 |
| LRM-341 | SV-CC | E.1 | Rework per Joao | Change | Section E.1 |
| LRM-342 | SV-AC | Numerous | Changes from Surrendra in PDF/Frame | Change | |
| Frame | |||||
| LRM-343 | SV-EC | 4.13 | Added 4.13 on Associative Array Literals per Arturo | Change | Section 4.13 |
| LRM-344 | SV-CC | F.2 | Correct cross reference per Francoise | Change | Section F.2 |
| LRM-345 | SV-BC | 19.5.2 19.5.4 | Bold on keywords from Jonathan Bradford comments per Dave | Change | Section 19.5.2 Section 19.5.4 |
| LRM-346 | SV-BC | 4.2 | Clarification of shortcut from Jonathan Bradford's comments per Dave | Change | Section 4.2 |