My concern isn't necessarily with unique0; I am more concerned with the general direction of encoding warning control mechanisms in keywords. If unique0 is the only such case we will ever need (or foresee ever needing), then I'm fine with it. What I don't want to see happen is that this will become a precedent for "families" of keywords to have detailed warning control. module_no_port_coerce_warning might be a slightly amusing and relevant example... Gord Steven Sharp wrote: >> From: Gordon Vreugdenhil <gordonv@model.com> > >> I am uncomfortable with 2131. It is setting a precedent that >> a keyword distinction is needed (and appropriate) to get a >> different level of warning reporting. > > My take on it was that it was another distinct set of conditions > to be checked, just as unique and priority check different > conditions. The only weakness I see in the analogy is that > unique0 is almost the same as unique, and that the same checking > can already be gotten by using unique and adding an empty > else/default clause. > > If this idiom is common enough, the convenience might justify > the extra keyword. > >> I know that we have previously stayed away from standardizing >> attribute forms but it seems to me that we should at least >> be considering this more thoroughly before adopting the keyword >> approach. Since there seems to be some tendency to add >> required warnings, if we want to standardize control over the >> conditions and forms of such warnings, I'd like to have that >> discussion explicitly. > > The step of standardizing an attribute for this one case seems > bigger than adding another keyword. If this were viewed as > turning off one of the standard warnings, and there was reason > to expect the addition of more such controls, then I would agree > with you. But this can be viewed as just another set of conditions > distinct from the ones for unique and priority, and different > keywords have already been used for that. I don't see an indication > that other variations of this will be proposed (what other variations > are left?) > > For this one case, I don't think users would bother with learning > a new attribute-based mechanism. If there is no unique0, I expect > they will just add an empty else/default. > > Steven Sharp > sharp@cadence.com > > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Dec 17 08:35:19 2007
This archive was generated by hypermail 2.1.8 : Mon Dec 17 2007 - 08:35:39 PST