 |
 |
On Mon, 2014-11-10 at 09:38 +0900, Malcolm Cohen wrote: > >There was an interp that resulted in > > > > integer, parameter :: N = bit_size(n) > > > >being illegal. How is this one different? > > That's a confusing question, since I indicated that I did think it was > (probably) outside the standard... Maybe we need to revisit interp f95/000090. The fourth and sixth examples were 4. character :: C(10)*(size(c,1)) 6. integer :: B = bit_size(b) The answer was "None of the examples are legal." The current text of the standard, that Malcolm referenced below, makes example 4 clearly illegal, because the inquired property is specified within the same <entity-decl>, viz. "C(10)*(size(c,1))". But in example 6, is the property specified by "integer ::" or by "B"? > The interp was Fortran 95, so pretty ancient history, and mostly asking > about things like > > INTEGER :: P(complicated_expression_for_lower_bound_1: & > & complicated_expression_for_upper_bound_1, & > & complicated_expression_for_lower_bound_2: & > & complicated_expression_for_upper_bound_2) = & > & RESHAPE( (/ 11, 21, 12, 22 /), SHAPE(P) ) > > and the answer was that that was not allowed (plus a whole load of others). > > The relevant text in the standard is > > "If a constant expression includes a specification inquiry that depends on > a type parameter or an array bound of an entity specified in the same > specification-part , the type parameter or array bound shall be specified in > a prior specification of the specification-part . The prior specification > may be to the left of the specification inquiry in the same statement, but > shall not be within the same entity-decl ." > > Now, in the case of "double precision :: max_allowed...", the question is > whether the specification of the type and kind are considered to occur at > the type-spec, or whether they occur at the (first) occurrence of > "max_allowed". If the former, there is nothing wrong. If the latter, it > is beyond the standard. From the text of the interp answer, one would think > the latter, but the text in the standard itself is not 100% clear. > > (And I think that few if any compilers will reject or even warn about this > particular case.) > > I rest my case with "at best, confusingly bad style". > > Cheers,