Language Change Specification for Conditional Expressions and/or Operators Proposal

Voting Results: Cast your votes here

Yes:

1. Thomas Preusser - 2016-12-20
2. Ryan Hinton - 2016-12-22 , ver 5
3. Patrick Lehmann - 2016-01-19 , ver 5
4. Daniel Kho - 2017-1-19 Ver 5
5. Lieven Lemiengre - 2017-01-27 ver 5
6. Jim Lewis - 2017-02-15 ver 7
7. Yann Guidon - 2017-02-19
8. Rob Gaddi - 2017-02-20 ver 7
9. Peter Flake - 2017-03-09 ver 7

No:

1. Farrell Ostler - 2017-1-31 ver 5 - Not convinced that it is a good idea to introduce "unaffected" into expressions; needs more analysis and vetting IMHO.

Abstain:

1. Brent Hayhoe - 2017-02-16 Version 6 - Abstain due to lack of personal time for review.

2. Kevin Jennings - 2017-02-28 Version 7 - Lack of time to review

Reviewing Notes

Related Context

This is the baseline version allowing unaffected only in the context of dynamic variable and signal assignments.
For further generalizations of unaffected see:

• LCS036b - conditional definition of attribute values, and
• LCS094a - conditional return statement.

Proposal Intent

This proposal introduces first-class conditional expressions. Their use as top-level expressions subsumes the existing conditional variable assignment and the expression-based conditional signal assignment. New use cases are implied for constant definitions and attribute specifications. Additionally, a conditional expression may now be nested within a parenthesized primary expression.

This proposal enables a concise and intuitive notation naturally extending the established syntax of existing conditional assignments using when. New use cases for declarative items or within nested expressions are enables, e.g.:

  -- Conditional expressions to compute declared constants and attribute values
  constant DELAY : time := 3 ns when FAST else 5 ns;
  attribute RAM_STYLE of RegFile : signal is "distributed" when SMALL else "block";
...
  -- Nested conditional expressions in implementation
  y <= a xor b after (3 ns when FAST else 5 ns);
  report "Test: "&("PASS" when errors = 0 else "FAIL") severity note;

Note that the expression-based conditional signal and variable assignments are subsumed by this proposal - with a significant reduction of LRM text that needs to be maintained. For this purpose, the apparently little-known unaffected assignment has received a little more attention and is used as the formal capture of a missing final unconditional choice. It is to be allowed on the outermost nesting level of an expression. Its use subsumes the existing conditional signal and variable assignments without a trailing unconditional choice.

Comments

This LCS focuses on attribute specification, but does nothing for the constant, variable, and signal declarations as shown in proposal implementation 2 and mentioned in the proposal requirements.

Suggested adjustment to LCS approach: Modify conditional_expressions to allow it to reduce to a single expression (no when), then redefine the productions for declarations to use conditional_expression instead of expression. This may require an adjustment to a force_assignment rule to avoid ambiguity. Also, some additional text would be needed that explains the semantics when no when is present. Currently the semantics are given by the equivalences shown in 10.5.3.

-- Ryan Hinton - 2016-12-19

Thanks for your comment. I have moved to making conditional expressions first-class citizens now to cover a wider range of use cases.

-- Thomas Preusser - 2016-12-20

This looks much better. Further suggestions:

• Keep the top-level expression grammar rule if for no other reason than it encapsulates what mathematicians expect for an "expression".
• Don't move the conditional_operator_primary to the next rule. Create a new conditional_expression rule instead. The progression of the grammar rules encodes the precedence of the operations -- we don't want to mess with that. For reference, take a look at the way Peter added another rule in his UnaryPrecedence proposal. I imagine something like the following.

expression ::= 
  condition_operator primary
| conditional_expression

conditional_expression ::= 
  logical_expression { when condition else expression } [ when condition ]

logical_expression ::= ... (unchanged)

• Then can we get rid of the conditional_expressions rules and text (10.5.3)? My goal for your approach is to reuse or replace this construct.
  -- Ryan Hinton - 2016-12-20
  Thanks, Ryan. I think I can get the expression grammar re-organized. However, I will not allow an expression to be a conditional expression directly. It must be parenthesized. Otherwise, we are running into a whole lot of ambiguities if actually conditional expressions are used as time or value expressions in conditional waveform specifications or as conditions in general. So, top-level conditional expressions without parentheses must be restricted to carefully selected contexts where they essentially resemble the whole right-hand side of a statement.
  It appears that you are missing the semantic expansion of the conditional variable and the expression-based conditional signal assignment. While this expansion still makes sense for the conditional waveform (which cannot be subsumed by the conditional expression), the expression-based use cases really turn into simple assignments, Their inherent choice is subsumed by the now conditional expression. Note that this way even saying that the force mode of a conditional signal assignment needs to be copied to all choices is no longer necessary because there is only one single expression value involved in the assignment.
  -- Thomas Preusser - 2016-12-21
  Good points. I like where this is going.
  RH#1: It would be nice to simplify the semantics description. Also, my reading of your description seems to link it with the type expected by the context. From what I can tell, the types of VHDL expressions should be determined without having to look at the context. Here is some suggested text for starters.
  "All of the candidate result expressions in a conditional expression shall have the same base type, except for candidate results that consist of the keyword unaffected, if any. All of the condition expressions must have type BOOLEAN. The value of the expression is one of the following, in order of preference:

• the value of the result candidate expression preceding the first condition that evaluates to TRUE, if any;
• the value of the final candidate expression if the final candidate result has no condition; or
• the special value unaffected.
  The special value unaffected is compatible with any type context. Its semantics are specified where it is allowed. Unless semantics are explicitly specified (signal assignment, variable assignment, attribute specification), it is an error for a conditional expression to produce the value unaffected."
  RH#2: I put some effort into this text to avoid implying short-circuit semantics. The same-type requirement implies that we need to be able to evaluate all of the expressions, so short-circuit semantics seem unnecessary.
  RH#3: Is it worth the effort to specify semantics for association lists (port map, generic map, and subprogram parameters)? In this context I imagine unaffected would be equivalent to open.
  RH#4: Should a constant initial value of unaffected be equivalent to a deferred constant?
  RH#5: Should a signal or variable initial value of unaffected be equivalent to the declaration without an initial value?
  RH#6: Should we move the definition of the "condition" grammar symbol to this section (from 10.2 currently)?
  RH#7: I agree that the conditional waveform can't be subsumed by the conditional expression.
  RH#8: Your changes for 10.5.3 still have a "conditional_expressions" production for the conditional force assignment. With the conditional expression, can't we get rid of the conditional_force_assignment and conditional_expressions rules altogether and modify the simple_force_assignment to take a conditional_expression? If we do this, we need to change your green text in 10.5.3 to something like, "If the expression of a simple signal assignment evaluates to unaffected, the statement is to behave like a sequential null statement." And maybe we should move this text and the conditional variable assignment text to the corresponding "simple" sections. Actually, this case for signals is already described at the top of page 151.
  RH#9: I suggest changing "expression_or_nop" to "expression_or_unaffected". It's a little longer but more explicit.
  RH#10: I suggest adding a bullet for "after the when in a conditional expression" to the bulleted list in 9.2.9. This list will need some work since we're getting rid of (at least) the conditional variable assignment production.
  RH#11: Fair warning, I just had to add all the deleted text to one of my proposals before Jim would vote on it. I think lots of deleted text is a mark of an excellent proposal! (Why didn't they do this before?!)
  My additional semantics suggestions can wait until the next language revision, of course. But then people may be wondering why we didn't add it this time.
  Thanks for your patience and good work!
  -- Ryan Hinton - 2016-12-21
  In the statement, "(Remove production now subsumed by the expression syntax.) " You need to show the removed production in lined out red.
  One basic rule: you cannot break old code. Hence, conditional signal assignments still need to handle waveforms (multiple after). Does this proposal allow that? If it does, then how do you deal with the ambiguity of the simple case of a waveform being the same as an expression?
  I suspect that if you expand conditional expressions beyond initialization of constant, variable, and signal and into a general thing, that you will need to use if rather than when to disambiguate between conditional signal waveforms and a conditional expression. I don't necessarily see this as an issue as I would expect the when form to die out over time and be replaced by the if form.
  -- Jim Lewis - 2016-12-22
  Correction to RH#8. I got confused by the colors. Other LCS pages are using red f

 conditional_waveform_assignment ::=
    target <= [ delay_mechanism ] conditional_waveforms ;     (sequential version) 

 concurrent_conditional_signal_assignment ::=
    target <= [ guarded ] [ delay_mechanism ] conditional_waveforms ;     (concurrent version) 

 conditional_waveforms ::=
    waveform when condition
    { else waveform when condition }
    [ else waveform ]

 condition ::= expression

 waveform ::=
    waveform_element { , waveform_element }
  | unaffected

 waveform_element ::=
    value_expression [ after time_expression ]
  | null [ after time_expression ]

Similar to how conditional signal assignment is constructed, we only allow the conditional_expression production in select places that resemble the whole right-hand side of a statement (quoting Mr. Preusser): attribute specification, constant initialization, (I hope variable and signal initialization,) and variable assignment. Applying these rules to your FT-10 examples gives the following.

• EX_1A: syntax unchanged, uses conditional signal assignment.
• EX_1B: parenthesized expressions now use conditional_expression production but reduce to a single expression, so the semantics are the same.
• EX_1C: the parenthesized expression uses the conditional_expression production as proposed.
• EX_2A: syntax unchanged, uses conditional signal assignment.
• EX_2B: syntax unchanged, uses conditional signal assignment.
• EX_2C: simple_waveform_assignment where the parenthesized expression uses the new conditional_expression production.
• EX_3: conditional_waveform_assignment or concurrent_conditional_signal_assignment where the parenthesized expression uses the new conditional_expression production.
• Sync reset line 2.35: similar to previous.
• Sync reset line 2.38: no change, uses conditional signal assignment.
• Async reset line 2.44: no change, uses conditional signal assignment.
  So all of the formerly valid and proposed syntax works as desired. In fact, I can still use the conditional expression in a variable or signal initialization as written at the moment if I put parentheses around it. (Note to Mr. Preusser: let's keep the rule consistent between constant, signal, and variable initialization -- either all of them work without parentheses, or none of them. I want it to be the same whenever I type ":=".)
  -- Ryan Hinton - 2016-12-22
  Suggested additional changes to named sections and summary:

 interface_constant_declaration ::=           [§ 6.5.2]
    [ constant ] identifier_list : [ in ] subtype_indication [ := static_conditional_expression ]

 interface_signal_declaration ::=             [§ 6.5.2]
    [ signal ] identifier_list : [ mode ] subtype_indication [ bus ] [ := static_conditional_expression ]

 interface_variable_declaration ::=           [§ 6.5.2]
    [ variable ] identifier_list : [ mode ] subtype_indication [ := static_conditional_expression ]

(constant declaration included in current text)

 signal_declaration ::=                       [§ 6.4.2.3]
    signal identifier_list : subtype_indication [ signal_kind ] [ := conditional_expression ] ;

 variable_declaration ::= [§ 6.4.2.4]
    [ shared ] variable identifier_list : subtype_indication [ := conditional_expression ] ;

I don't think any text would need to change.

-- Ryan Hinton - 2016-12-22

Thank you very much for all your comments!

Ease of Reading: I will add a strike-through to deletions to make things more obvious and avoid confusion.

Ambiguities: As Ryan already noted, ambiguities are avoided by not letting a conditional expressions take the place of an expression in general. A conditional expression can only be used in a place that requires a regular expression if it is parenthesized. So, you only have at most one sequence of when s on a particular level of parentheses. Conditional waveforms, of course, stay around. Their value expressions are regular expressions so that their when structure cannot be confused with that of a conditional expression. If a when is to be used within such a value, a condition or a time expression, it must be parenthesized. By the way, a similar strict parenthesezation is used for the conditional expressions in ADA.

Other Initializations: Thanks Ryan for spotting these shortcomings. Of course, we should allow conditional expressions without parentheses in other initializers. I will happily add this to the proposed text.

-- Thomas Preusser - 2016-12-22

@Ryan: I have adopted most of your proposals. Some points may be worth more thorough thinking:

RH #3: As we have not explicitly allowed unaffected in the context of association lists, the current strict reading would not allow it at all. Conditional overrides of default generics might be interesting though. For the conditional wiring of ports, I cannot really think of a great use case.

RH #4: Again, the current reading does not allow to defer the computation of constants dynamically by yielding unaffected. If this was allowed, you must be able to switch on and off the deferred definition in the package body as well - using the inverse condition. Is this sensible?

-- Thomas Preusser - 2016-12-22

RH#3: Yes, if we like this idea, we'll need to add some text in 6.5.2. For ports, a result of "unaffected" is congruent to "open" -- possibly more useful than overriding generics. This could dovetail nicely with partial association.

RH#4: Yeah, using unaffected for a deferred constant isn't a great idea. I was brainstorming, trying to think of what it might be defined to mean in different contexts. Drop this one.

-- Ryan Hinton - 2016-12-23

It looks like we have two copies of this proposal, one with a capital 'A' at the end, and another with a lower-case 'a' at the end. I'll let you decide which one to keep and link from the proposal page and collected requirements page. I voted 'yes' on one of them. Let me know when they're consolidated, and I'll make sure I'm still affirmative.

-- Ryan Hinton - 2016-12-23

Well, the capital-A version is my secret shadow copy for drafting the next version. I will never link it officially. It comes in handy when the server keeps the original page locked on an edit that has not been completed properly.

I will look into working out some text for RH #3.

-- Thomas Preusser - 2016-12-23

@Thomas Looking much better - either that or I am doing a better job reading it

Keep in mind, your directions here need to be the complete directions with context. The LRM editor should be able to be a non-VHDL person who is just mindlessly following your directions. The previous revision we spent a significant sum to have a smart editor. For this revision we have no money.

In particular, in section 9.1, it would be helpful to have some of the unchanged productions to make sure the order of the added items is consistent with the rest of the list. Being specific, I think that conditional_expression becomes the first item in the list and not after the primary as you have it shown above. I would also note that more context here would help us review that section more thoroughly without having to flip back and forth between an existing LRM.

In December 1, 2016 meeting, the formatting for new proposals was updated. Please use red for changes and not green. For comments, please use a notation to distinguish them from regular text - both Ryan and I have been using green. I am also enclosing mine in [ ]

-- Jim Lewis - 2016-12-24

@Jim: I have fixed the formatting and added some more context.

@Ryan: Added edits to 6.5.7.1 to take care of your RH#3.

Moving up to revision 5. I hope to get close

-- Thomas Preusser - 2016-12-25

@Ryan: There are some aspects of RH #3 that go beyond what one should do with expressions. Associations of concrete objects such as signals and variables with a formal may be interpreted as very simple expressions but they are currently treated differently on the basis of their names. I would like to avoid dragging these cases into this expression-based proposal as it seems to me that this would break with the current style VHDL is specified and would probably require C++-like terminology such as lvalue references. So I think that full-featured conditional signal or variable associations should go into their own LCS. Of course, I would greatly advocate following the same syntax concept producing associations like:

  ...
  port0 => sig0 when cond0 else sig1,
  port1 => sig2 when cond1,
  ...

However, these actuals cannot be interpreted as expressions as soon as you are considering the wiring of output ports.

-- Thomas Preusser - 2016-12-27

This looks great. Thanks for all your work to refine and polish it.

Changes I made:

RHv5#1: I made a few editorial changes. In particular, it looks like Twiki doesn't make things bold using the '*' syntax inside of a "pre" tag. I've fixed the incidences I saw using the boldface tag "b".

RHv5#2: I provided a little more context around the conditional signal assignment edit.

RHv5#3: I removed some text at the beginning of 10.5.3 that is no longer relevant regarding force/release.

RHv5#4: I added a strikeout to the condition production removed from 10.2.

RHv5#5: I combined some of the pre-formatted sections. Each section has its own horizontal scroll bar for me, but it's easier to read in larger chunks.

Changes I suggest but did not make:

RHv5#6: Re-reading, I recommend we get rid of the parenthetical content in 9.1: "Unless semantics are explicitly specified (signal assignment, variable assignment, attribute specification), ...." It seems easier to maintain and extend the LRM when information is kept in exactly one place whenever possible.

RHv5#7: In the change to section 10.5.3, I think we want to remove the "unaffected" text ("If the expression of a conditional...."). Conditional signal assignment is defined in terms of an "if" statement and simple signal assigment. Simple signal assignment already has text to handle unaffected (top of page 149). Or does this new language handle a case I'm not seeing?

RHv5#8: Now that you adopted my suggested text for 9.1, I don't like it. In particular, someone could argue that unaffected has the lowest preference (third bullet), so if multiple conditions evaluate to true, then the first one that isn't unaffected should be chosen. I think that's a poor interpretation. I think the text is sufficient as it is, but it could be better. Here's another try. Let me know what you think.

All of the candidate result expressions in a conditional expression shall have the same base type, except for candidate results that consist of the keyword unaffected, if any. All of the condition expressions must have type BOOLEAN. (No changes to the first part.) A conditional expression in which the final choice has a condition is implicitly completed for the purpose of evaluation by adding a final unconditional expression, unaffected. ("Completing" the conditional expression converts our 3-4 cases into two cases.) The value of a conditional expression is the value of the expression preceding the first condition that evaluates to TRUE, if any. Otherwise, the value is the final, unconditional expression.

-- Ryan Hinton - 2016-12-27

I'm confused by your exclusion of association lists (discussed in your 12-26 comment) because the proposed grammar text does allow conditional expressions in an association list. Can you help me understand what is and is not allowed?

-- Ryan Hinton - 2016-12-28

@Ryan: The production specified for the actual_part is all but unambiguous. Everything that looks like a name or even a function call can only be categorized by context. The paragraphs following the grammar section try to do this. In essence, function calls, type conversions and expressions are allowed to support conclusive type adjustments. For very simple cases. i.e. one argument and one result, even the conversion of an out parameter to the type of the associated actual is supported. Otherwise, there is no generic way to compute an expression kind of backwards. Only carefully selected, well-defined and intuitive scenarios should be supported and must be specified explicitly.

The association of an actual signal or variable with a formal is covered by the signal_name and variable_name expansions, not by the expression. This direct association is intuitive and works in any direction. You could go ahead and remove the name-based expansions and consider them instances of simple expressions. Moving this way would require a re-write of the semantic specifications. Of course, this could also include the definition that a conditional expression selecting between immediately named objects must have static conditions and will result in at most one association or leave the port open otherwise.

It seems to me that this is another significant change that should into its own LCS.

-- Thomas Preusser - 2016-12-29

@Ryan: Thank you for the quick edits. I also re-wrote the semantics paragraph of 9.1 to take care of RHv5#6 and RHv5#8.

I am not so sure about RHv5#7. The text that you reference takes care of the unaffected in a simple_waveform_assignment. This is different from the simple_force_assignment. However, I agree that the "unaffected" text appears misplaced in 10.5.3 now. I will move the specification of unaffected to 10.5.2.1 instead.

-- Thomas Preusser - 2016-12-29

I made a few editorial changes.

I also made a more substantial edit to the conditional variable assignment section. Since there is no longer any conditional variable assignment, it seems silly to have a section for it. I moved the two sentences we had there to the "General" section and added instructions to delete 10.6.2 altogether. Feel free to change it back or in some other way if you prefer.

This looks great. Thanks for your work.

-- Ryan Hinton - 2016-12-29

Thanks Ryan! You have been a demanding and extremely helpful critic. Quite a bit of the outcome is due to your insistence and actually also your own work.

-- Thomas Preusser - 2017-01-01

IEEE replaced the verb "must" by "shall" so the wording "must not" shouldn't be used anymore in IEEE standards.

-- Patrick Lehmann - 2017-01-19

@Patrick: I have not found any "must not" in the text but have replaced a "must" by "shall" in §9.1. Thanks for the hint!

-- Thomas Preusser - 2017-01-19

Congratulations to Thomas Preusser and Ryan Hinton on the productive collaboration that produced LCS 36a. It was an exemplary working-group interaction!

Nevertheless, I don't support the proposal in its present form for these reasons:

(1) The generalization of the "unaffected" concept (taken from signal assignment but where it is apparently little used in the field) is a clever approach to some aspects (in particular conditional expressions when the union of conditions that does not equal TRUE). Nevertheless--and even though Thomas and Ryan appear to have systematically covered the consequences in the various contexts--it is not clear that that the benefits are large enough to justify the carrying cost of dealing with a meta value (the value unaffected) during expression evaluation and the amount of change to the LRM. I would prefer to table it for the 2017 LRM and reconsider it for the next revision so that it can be more carefully evaluated.

(2) I would like to see an LCS for conditional expressions that doesn't require as many textual changes to the LRM. Kevin Jennings' LCS 36 is perhaps too simple but it has the virtue of low impact to the LRM. Could we seek a solution that is relatively low impact but takes advantage of Thomas' and Ryan's improvements in syntax and completeness?

-- Farrell Ostler - 2017-02-01

@Farrell: (1) Thanks for sharing your concerns about unaffected. Although this certainly is a meta value, it does not really carry relevant simulation costs. The newly introduced contexts where it is allowed are very well-defined and a tool can easily choose to translate the unaffected into a conditional rather than implement some type of value tagging. In the end, allowing unaffected within both waveforms (with delay clauses) and expressions (without delay clauses) is also a contribution to a more orthogonal language. The currently little use of the explicit keyword is probably due to the fact that many designers do not know it. If you find yourself rewriting conditions in an attempt to move the unaffected case to the very end of a conditional waveform or expression, an explicit intermediate unaffected might be a better option to consider.

(2) The changes outside restructuring the expression syntax are mostly motivated by giving the unaffected case a sensible meaning. I believe that this is important to draw as much benefit from it as possible. For instance, consider the definition of attribute values. Giving you a means to condition the value assignment within the language itself provides much more flexibility than the otherwise only remaining option using conditional compilation.

-- Thomas Preusser - 2017-02-02

I have an issue with "unaffected" being used anywhere it is not currently being used. IE: when the target of the conditional assignment is a variable. Going further, what does the following mean

Y <= (a when c1='1' elsif c2='1' b else unaffected) and d ;

Is this one of your prohibited expressions? If not, in a design review, this is going to present a problem to find.

WRT initializing interface objects, there are already complicated rules that sometimes allow a port to be unconnected if it has a initialization and there are several other LCS already editing these sections.

Hence, at least for this revision, I think we need to keep the scope of where "unaffected" is allowed to be limited. To maintain backward compatibility we need to allow "unaffected" when the target of a conditional expression is a variable assignment. However, like Farrell, at this time, I would not allow other uses.

WRT to attributes, that you mention above, can you show an example where you would want unaffected, and hence, the attribute is undefined?

Besides, if we are conservative about "unaffected" in this revision, we remove some of the restrictions later if it is determined to be appropriate to do so.

-- Jim Lewis - 2017-02-10

@Jim: Yes, your example is not legal because unaffected is prohibited everywhere unless explicitly given a semantics. I will review the text to state explicitly that unaffected is never allowed in a nested expression but can only appear on the uppermost level. Would this address your concerns?

As for the attributes, I could imagine use cases involving RAM styles or FSM encodings that you would only want to fix for certain target platforms or for debug purposes, e.g.:

attribute fsm_encoding of State : signal is "gray" when TOOL_TYPE = "SIMULATION";

attribute ram_style of Regfile : signal is "distributed" when TOOL_NAME = "XST";

-- Thomas Preusser - 2017-02-10

FWIW, this would be quite nice right now. I have a tool "S" that adds timing-closure-killing logic around a block RAM unless you add a particular attribute. But using another tool "V" from vendor "X" issues a critical warning when I DO apply this attribute. Without trying both, it's hard to say whether conditional compilation or unaffected is better for handling this case. Usually conditional compilation is the technique of last resort.

-- Ryan Hinton - 2017-02-11

I have added a few illustrating examples of use in the Reviewing Notes section. I have also added a sentence that clarifies that a conditional expression nested within a primary may not yield unaffected. In consequence, unaffected can only be used on the outermost nesting level when its semantics are clearly specified. I will try to codify this restriction directly within the grammar before pushing up the version. I believe this should be possible.

-- Thomas Preusser - 2017-02-13

Moving to Version #6: I hope to have addressed Farrell's and Jim's concerns by removing the unaffected choice from expression nests. The current grammar contains them explicitly to the outer level of the symbol conditional_or_unaffected_expression. This symbol is only used in situations that explicitly define the meaning of an unaffected outcome. The former phrasing "illegal unless explicitly specified" is thus no longer required.

-- Thomas Preusser - 2017-02-13

This is a critical review. Please don't confuse this with negativity. I like this proposal and look forward to the adjustments that fix it.

1) Looking at the annex C, I can see that you forgot to update section 9.1. My review is based on 9.1 getting updated per the appendix.

2) Use of unaffected in a signal or variable declaration is probably an error. Allow a conditional expression but never unaffected. If a default value is needed, use type'left rather than unaffected to get the same functionality. This way we can reasonably distinguish between intentions and errors. My vote will remain no if this allows unaffeected. If the group decides to ignore this, then adjustments to the text needs to be made, as both signals and variables get initialized in the same way during elaboration and the text for the two is different and should not be.

3a) Use of unaffected in an interface object declaration cannot be allowed in this revision. My vote will remain a strong no if this is unaffected. During this revision, too many other changes are being made here (LCS_2016_001 for one, but I think there are others too) that I do not think it is safe to make this change in this revision. In addition, what I said in 1 above also applies, so I am not sure this would ever be a good thing. Keep in mind that an explicit initialization on an interface object implies you can leave it open and LCS_2016_001 makes these rules much more complicated - note it is rated #1 and has to take precedence here.

3b) 6.5.7.1. No way ever can an actual be unaffected. conditional_expression ok.

4) Attrribute specification is exactly like 2.

5) 9.1 2nd from last red paragraph has a stray ">"

6) 9.1 last red paragraph. "The semantics of the special value unaffected must be specified by the contexts that allow the use of a conditional or unaffected expression"

This sentence seems to say, if the LRM does not specify the value of unaffected in a place where conditional_or_unaffected_expression is allowed, then then LRM is broken. Hence, I don't think we need this sentence. I think we just need to tediously verify that such a statement exists.

7) 6.4.2.2. The productions in the annex explicitly specify where unaffected can occur. Hence, it is confusing for you to talk about unaffected where it cannot occur. For example in constant declarations - last paragraph of 6.4.2.2 - delete red sentence.

8) 10.5.3. The current rule for conditional_signal_assignment should be replaced by the rule for conditional_waveform_assignment and the non-terminal conditional_waveform_assignment should be deleted (it was added in 2008)

9) 10.6.2.1 the last edit of the section should read exactly like the last edit of 10.5.2.1

-- Jim Lewis - 2017-02-15

1) @Jim#2, @Thomas

I would allow unaffected in signal and variable declarations. But, of course a signal always requires a default value, because this will be the initial contents of the signal's driver, see 14.7.2. I think, the issue could be easily fixed by modifying the (red) addition to clause 6.4.2.3 as follows (blue is my proposed modification.)

The conditional expression may legally evaluate to unaffected. In this case, an implicit default value is determined as described in the following paragraph.

(The next paragraph should be part of LCS to ease the review process.)

EDIT: 2) @Jim#3b

What is the problem with unaffected for actuals if they behave like open?

Found the answer by myself. And for version 7 it is not of interest anymore.

-- Martin Zabel - 2017-02-15

@MZ Part of the original design of VHDL is to be a safe design language. Allowing unaffected when an simple, explicit alternative (such as type'left) that captures intent is available, erodes away at that. Hence, allowing unaffected in signal and variable declarations, simply is not needed and I cannot support allowing it.

In this revision I think we should strongly limit the uses of unaffected in expressions. We can always loosen the restrictions in the next revision.

-- Jim Lewis - 2017-02-16

JL1 - Fixed.

JL2 - Changed - I find conditional initializers including unaffected acceptable simply because implicit initialization is also part of VHDL. Nonetheless, I would like to move forward at least part of the way in this release.

JL3a - Changed - DITO.

JL3b - Changed - DITO.

JL4 - Kept - Specifying an attribute value has nothing in common with a signal or variable initializer. There is no implicit default value that would be aliased by unaffected. The use of unaffected has the distinct semantics of nullifying the attribute association with the listed objects altogether. This use case is illustrated in the reviewing notes and has been supported by Ryan's comment of 2017-02-11. I would really want to keep these semantics in this place and would urge you not to hold it captive for your approval.

JL5 - Fixed.

JL6 - Fixed.

JL7 - Fixed.

JL8 - Fixed.

JL9 - Fixed.

-- Thomas Preusser - 2017-02-16

I don't much like the use of "unaffected" for anything which is not run time, and therefore does not have a previous state to be affected. This includes declarations. Other words such as "default" would be better.

Most of all, I dislike its use in attribute specifications. An expression should return a value, not make a name disappear! This should be done by generate or conditional compilation/analysis.

-- Peter Flake - 2017-02-17

@Peter: There are no more uses of unaffected in declarations. So what do you want me to do?

If you support all but the use of unaffected for attributes, please vote "*yes* if use of unaffected for attribute values is removed".

-- Thomas Preusser - 2017-02-17

@Thomas WRT unaffected and attribute specifications, given that we are adding conditional compilation, which I suspect will be one of the first things vendors implement (it has been requested numerous times), I don't see why I need another, less obvious (think code review) way to do the same thing. At the end of the day, I think the most important thing we do is make code that is readable and intuitively obvious. This mechanism provides a short hand way to do something that is much harder to find. Ok. Make your case. Jim

-- Jim Lewis - 2017-02-17

@Jim: Conditional compilation is a crutch that will only help if you can base your decision exclusively on conditional compilation identifiers. Generics or other VHDL values are not accessible. Conditional attributes are more flexible, can use all VHDL values and, through LCS 006d/e, also the conditional compilation identifiers.

-- Thomas Preusser - 2017-02-17

@Thomas as are attribute specifications that tell a synthesis tool how to do its job Going further, having different, yet similar attributes that separate tool vendors use to denote the same thing is appalling. Users should revolt and demand that their vendors work together on a standard to address the situation.

Conditional compilation should be providing everything you need. You need to work through your use models. Examine what is missing. IE: for FPGAs do you need target device?

-- Jim Lewis - 2017-02-17

@Jim: I can kind of see your idealistic point. Working with real tools that simply do differ, I would personally prefer the greater flexibility and smoother language integration offered by having unaffected attributes on top of conditional compilation.

However, I see that this is mostly a point of personal taste and either decision would be completely valid from a technical point of view. Taking unaffected attributes in or out is just a small edit leaving or deleting the maroonized text in §7.2. So, we really only have to decide one way or the other. I could call for a secondary voting at the top of this page, or you could just come to a conclusion during the next meeting. While I do have an opinion, I would just follow suite on the majority opinion.

-- Thomas Preusser - 2017-02-19

@Thomas, The way we are doing secondary voting is to split out the contentious item. So why not specify here conditional_expression here and have a short LCS, 36b, which changes conditional_expression in 36a to conditional_or_unaffected_expression.

That way I can help you convince Farrell that he should vote yes on 36a.

WRT, " I can kind of see your idealistic point", VHDL originally had some design intentions. Some are good. Some are out of date due to improvements in compilers. We are out of time in this revision to talk about these, but before we start the next revision we should talk about what the intentions and principles are going forward.

-- Jim Lewis - 2017-02-24

@Thomas, WRT Peter's comments, I suspect he is referring to attribute specification since it is a declarative item.

-- Jim Lewis - 2017-02-24