!standard 6.1.2(0/5) 20-04-29 AI12-0375-1/02 !class Amendment 20-03-24 !status Amendment 1-2012 20-04-29 !status WG9 Approved 22-06-22 !status ARG Approved 13-0-1 20-04-29 !status work item 20-03-24 !status received 20-03-24 !priority Low !difficulty Easy !subject Meaning of Global when there is no mode !summary The global mode cannot be omitted before All or Synchronized !problem The syntax for the Global aspect is in part: global_aspect_definition ::= NULL | Unspecified | global_group_designator | global_mode global_designator | (global_aspect_element{, global_aspect_element}) | extended_global_aspect_definition -- see H.7 global_designator ::= global_group_designator | global_name global_group_designator ::= ALL | SYNCHRONIZED This allows All and Synchronized to appear without a global_mode. However, there is no rule that explains what these mean when the mode is omitted. !proposal (See Summary.) !wording Replace the global_aspect_definition and global_designator grammar in AI12-0079-3 with: global_aspect_definition ::= NULL | Unspecified | global_mode global_designator | (global_aspect_element{, global_aspect_element}) | extended_global_aspect_definition -- see H.7 global_designator ::= ALL | SYNCHRONIZED | global_name !discussion We could have added a line to the Static Semantics like: If a global_aspect_definition consists of a single global_group_designator, the global_mode is implicitly IN OUT. However, some reviewers thought it was unusual to have the mode default to IN OUT when it defaults to IN in other cases. Since the case where the mode would be IN is less likely than the case where the mode would be IN OUT, such a shorthand would be more confusing than simplifying. Thus we require the mode to be given. !corrigendum 6.1.2(0) @dinsc Dummy to force a conflict; the wording changes are in the conflict file. !ASIS [Not sure. It seems like some new capabilities might be needed, but I didn't check - Editor.] !ACATS test ACATS B- and C-Tests are needed to check that the new capabilities are supported. !appendix From: Randy Brukardt Sent: Sunday, March 22, 2020 8:08 PM [From a thread in AI12-0079-3:] Tucker also noticed that we're missing a rule. If the user writes Global => all or Global => synchronized the intent was to interpret that as "in out all" or "in out synchronized". He suggested adding the following to the paragraph immediately following the BNF: If a global_aspect_definition consists of a single global_group_designator, the global_mode is implicitly IN OUT. This second change seems to be a clear oversight that should not be controversial, so I am processing it as an Editorial Review change. **************************************************************** From: Claire Dross Sent: Monday, March 23, 2020 8:57 AM > This second change seems to be a clear oversight that should not be > controversial, so I am processing it as an Editorial Review change. I am not thrilled by this one. Usual default is *in* (for subprogram parameters for example), I would find it more consistent to stick with that. **************************************************************** From: Bob Duff Sent: Monday, March 23, 2020 9:35 AM I admit I haven't followed the global thing closely, but I think I agree with Claire on this point. **************************************************************** From: Richard Wai Sent: Monday, March 23, 2020 9:39 AM I agree with Claire. I don't think making in out default is worth it to avoid having to always write "in out all/synchronized" **************************************************************** From: Tucker Taft Sent: Monday, March 23, 2020 10:11 AM > I am not thrilled by this one. Usual default is *in* (for subprogram > parameters for example), I would find it more consistent to stick with that. I would eliminate the default completely if we cannot agree on IN OUT. "Global => All" or "Global => Synchronized" have been used in several examples to indicate all access, or all synchronized access. For them to mean read-only access would be counterintuitive to me, so I would argue for requiring explicit modes if you find this shorthand to be ambiguous. **************************************************************** From: Tullio Vardanega Sent: Monday, March 23, 2020 10:28 AM I am with Tuck on this one. **************************************************************** From: Brad Moore Sent: Monday, March 23, 2020 8:58 PM Myself as well... **************************************************************** From: Randy Brukardt Sent: Monday, March 23, 2020 9:16 PM [Rewriting lost mail...] ... > I would eliminate the default completely if we cannot agree on IN OUT. > "Global => All" or "Global => Synchronized" have been used in several > examples to indicate all access, or all synchronized access. For them > to mean read-only access would be counterintuitive to me, so I would > argue for requiring explicit modes if you find this shorthand to be > ambiguous. I agree with Tuck (and Tullio). It seems that "in out all" will be substantially more common than "in all" (esp. as there is no package-level way to specify groups of globals). It doesn't make a ton of sense to have a short-hand for the less likely case. Anyway, since this topic obviously is not the "obvious oversight" that I expected, I've split it out into a separate AI and we can consider it properly. It's clearly isn't something that should get stuck in by editorial review. P.S. Our area is going to be locked-down starting tomorrow, so I won't be able to get into the office to do Ada-Auth.org website updates, or to moderate or otherwise rescue your e-mail. The lists and website should be able to run on their own (much like they do when I'm on vacation). **************************************************************** From: Jeff Cousins Sent: Wednesday, March 25, 2020 2:07 PM Sorry, but to be clear, when people say that they agree with Tuck, do they mean his first option, i.e. the default should be “in out all” or his second option, that there should be no default and explicit modes are required ? **************************************************************** From: Randy Brukardt Sent: Wednesday, March 25, 2020 2:19 PM Yes. ;-) I'm OK with either, but i'm assuming the first will not fly. So I wrote it up to remove the ability to have a default mode. See the posted AI12-0375-1. **************************************************************** From: Tucker Taft Sent: Wednesday, March 25, 2020 2:25 PM I interpreted it to mean that a default of "in" would be confusing, so we should remove the default as an option, and require an explicit specification in all cases, including for "all" and "synchronized." **************************************************************** From: Tullio Vardanega Sent: Wednesday, March 25, 2020 2:43 PM That's what I meant. **************************************************************** From: Jeff Cousins Sent: Wednesday, March 25, 2020 3:01 PM Thanks for the clarification. **************************************************************** From: Brad Moore Sent: Thursday, March 26, 2020 2:02 PM I meant that I agreed with Tucks argument, I didn't state a preference over sticking with Tuck's original suggestion as "in out" or removing the default, only that if we cant agree on "in out", we should remove the default. I haven't made up my mind between those two yet, but either of these two options would be preferable to me over going with "in". ****************************************************************