!standard 9.5(32/5)                                   20-10-14    AC95-00334/00
!standard 9.5(33/5)
!class Amendment 20-10-14
!status received no action 20-10-14
!status received 20-09-21
!subject Query about the Nonblocking aspect
!summary

!appendix

From: Jeff Cousins
Sent: Monday, September 21, 2020  12:16 PM

Maybe I’ve missed it, but I can’t see anything in the new wording to indicate 
why one would want to apply the Nonblocking aspect to entities other than 
callable entities.  Presumably the intent is that applying Nonblocking to a 
package is setting the default for subprograms within it (which is what the 
discarded 64-1 said), and applying Nonblocking to a type is setting the 
default for the type’s primitive subprograms, but where is that stated?

(Also, there is a lot of talk about “operations”, but as 380 mentioned, that’s 
not a defined term.)

***************************************************************

From: Tucker Taft
Sent: Tuesday, September 22, 2020  1:11 PM

I think you might have missed it.

Paragraphs 9.5(32/5, 33/5) establish the use of the Nonblocking aspect on 
program units, as a default.  Later, in paragraphs 9.5(51/5 - 59/5) there are 
legality rules that talk about subtypes, composite types, controlled types, 
etc.

There certainly might be some holes, but hopefully some of these were 
addressed in the most recent AI on aspect fix-ups.

***************************************************************

From: Jeff Cousins
Sent: Tuesday, September 22, 2020  3:07 PM

Many thanks Tuck.

> Paragraphs 9.5(32/5, 33/5) establish the use of the Nonblocking aspect on 
> program units, as a default.

Think I lost that in all the mark-ups in the AARM with changes highlighted!

> Later, in paragraphs 9.5(51/5 - 59/5) there are legality rules that talk 
> about subtypes, composite types, controlled types, etc.
 
This was because I was expecting something else.  I was thinking that setting 
the aspect for a type would set the default for all its predefined operators, 
and the only query would be about whether or not it also set the default for 
its primitive subprograms.  So this is not so?  The only predefined operator 
I can see mentioned is equality, I was assuming, evidently incorrectly, that 
not mentioning the other operations was an omission.

But at least I think I’ve just spotted a typo! (53/5) “AIt is illegal”

***************************************************************

From: Tucker Taft
Sent: Tuesday, September 22, 2020  3:50 PM

...
>This was because I was expecting something else.  I was thinking that setting 
>the aspect for a type would set the default for all its predefined operators, 
>and the only query would be about whether or not it also set the default for 
>its primitive subprograms.  So this is not so?  The only predefined operator 
>I can see mentioned is equality, I was assuming, evidently incorrectly, that 
>not mentioning the other operations was an omission.

It mentions initialize, Finalize, and Adjust for controlled types in (58/5).  
It mentions operations performed during default initialization of record 
components in (57/5).  So "=" is not the only operation mentioned...
 
>But at least I think I’ve just spotted a typo! (53/5) “AIt is illegal”

That one I do remember fixing as part of AI12-0396-1, fix-ups for aspects of 
aspects.

***************************************************************

From: Jeff Cousins
Sent: Tuesday, September 22, 2020  4:29 PM

Thanks again Tuck.

> It mentions initialize, Finalize, and Adjust for controlled types in (58/5).  
> It mentions operations performed during default initialization of record 
> components in (57/5).  So "=" is not the only operation mentioned...

I'd spotted them, but was thinking of them as special cases, picked out as if 
to say "and don't forget these less obvious operations".

What "common" predefined operations might block I don't know, but I don't 
suppose it would enter the heads of most users that equality might block.

***************************************************************