(j3.2006) Future deprecation of overriding character length, dimension and codimension

Bill Long longb
Wed Feb 22 11:22:22 EST 2017


On Feb 22, 2017, at 9:37 AM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov> wrote:

> Ugh.   I would have been happy never being aware of this wart.   Don?t think I?ve ever seen it in actual code.

Unfortunately, I have. We could propose it be made Obsolescent.  No reasonable coding style guide would permit this sort of thing. But vendors will have to continue supporting it, so ?deleted? is less realistic.  [It is unfortunate that we let this disease spread to codimension.]

Note that character*n is already Obsolescent. Which is a good thing, since that syntax falsely gives some users the idea that real*n and integer*n are also standard.  If it were not for existing code, I?d favor deleting character*n. 

Cheers,
Bill


> 
> (Deleting several mean-spirited suggestions I had for actions to take on such users.)
> 
> 
>> On Feb 22, 2017, at 9:11 AM, Steve Lionel <steve at stevelionel.com> wrote:
>> 
>> The standard currently allows character lengths, dimensions and 
>> codimensions to be multiply specified in a declaration. For example:
>> 
>> character(len=10), dimension(30)            :: foo2*50(20)
>> ! or
>> character*10     , dimension(30)            :: foo3*50(20)
>> ! or
>> real, codimension [3,*] :: foo4[10,*]
>> 
>> 17-007 8.2:
>> 
>> p1 The type and type parameters are those specified by 
>> declaration-type-spec, except that the character length type parameter 
>> may be overridden for an entity by the appearance of * char-length in 
>> its entity-decl.
>> 
>> p2 The type declaration statement also specifies the attributes whose 
>> keywords appear in the attr-spec, except that the DIMENSION attribute 
>> may be specified or overridden for an entity by the appearance of 
>> array-spec in its entity-decl, and the CODIMENSION attribute may be 
>> specified or overridden for an entity by the appearance of coarray-spec 
>> in its entity-decl.
>> 
>> This can be very confusing and I would like to see such "overriding" 
>> deprecated in a future (2020?) standard so that processors are required 
>> to have the capability of diagnosing this. I'm not aware of any other 
>> place in the language where such overriding is allowed. Thoughts?
>> 
>> Steve
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Support  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101





More information about the J3 mailing list