J3/99-265 Date: 30th November 1999 To: J3 From: Malcolm Cohen Subject: Unresolved issues 205, 206, 207 1. Introduction These issues are all about expression classification (initialization vs. constant, etc.) and the IEEE modules. 2. Issue 205 This says essentially nothing that is not adequately covered by issue 132. The issue with IEEE_SELECTED_REAL_KIND is a red herring - there are other cases where initialization expressions are not constant expressions (e.g. parameterised derived types with kind type parameters). 3. Issue 206 This says "Why just IEEE_SELECTED_REAL_KIND and not anything else from the IEEE modules..." Because the whole purpose of IEEE_SELECTED_REAL_KIND is for it to be used in kind specifiers i.e. in initialization expressions. Omitting this functionality was an inadvertant oversight in the first edition of the TR. There is, I believe, no controversy about allowing IEEE_SELECTED_REAL_KIND in an initialization expression: it was an obvious mistake to make the function completely useless in the first edition. It is to be included in the next edition of the TR. The next edition of the TR does not allow anything else from the IEEE modules in initialization expressions. 4. Issue 207 This says "... all the functions in the IEEE modules are specification functions. This might be worth mentioning in a note..." I disagree. The functions in the IEEE modules are not the sort of function one is particularly likely to want to invoke in order to calculate an array bound. It is only worth noting this sort of thing if it is likely that a significant number of users will want to do it. 5. Edits [136:24-28] Delete. {Delete J3 note 207.} [138:30-47] Delete. {Delete J3 note 205.} [139:1-9] Delete. {Delete J3 note 206.}