(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