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

[Bill Long]

On Feb 22, 2017, at 7:37 PM, Cohen Malcolm <malcolm at nag-j.co.jp> wrote:

>> Ugh.   I would have been happy never being aware of this wart.   Don?t 
>> think I?ve ever seen it in actual code.
> 
> A not uncommon style used to be to put all the length specs on the variables 
> instead of on the type name, e.g.
> 
>          CHARACTER A*10,B*4,C*99
> 
> This has obvious advantages if you are declaring character variables with 
> lots of different lengths.
> 

True, but that seems to be quite uncommon.  We already made character*n obsolescent since using the ?*n?  scheme for specifying type parameters is obsolete and undesirable.  I think the same argument should apply to A*10.   But, as Steve pointed out, that was not his proposal.  Rather he wants to prohibit specifying the type parameter or dimensions TWICE in the same statement and having one override the other. 


> I don't think there is anything wrong with this.  I do not support making 
> this obsolescent at this time.
> 
> Re DIMENSION and CODIMENSION, in my opinion it is the attribute on the 
> type-spec that is obsolescent, not the one in the entity-decl.  I'd much 
> rather deprecate those!  We can deprecate the DIMENSION and CODIMENSION 
> statements while we are at it, they serve no other purpose than to promote 
> unsafe programming practices.

Specifying a dimension attribute in a declaration does allow you to declare several arrays of the same shape, which can be less error prone if the dimension expressions are complicated. 

However, I do agree that the separate statement forms of most of the attributes are obsolete, unhelpful, and their use results in less readable and maintainable code.  I find separate PARAMETER statements particularly annoying.   The only statement forms that are really justifiable are the ones that can change the attribute for a variable in a contained scope, such as VOLATILE or ASYNCHRONOUS. 


Cheers,
Bill



> 
>> I'm not aware of any other
>> place in the language where such overriding is allowed.
> 
> The way ASYNCHRONOUS and VOLATILE work (unlike every other specification 
> statement, they override the host associated entity's lack of those 
> attributes instead of creating a local entity) is much more confusing than 
> this.
> 
>> a paper that has to be passed by a majority?
> 
> It's WG5, and it's far too late to make technical changes that are not 
> fixes.  This is not a fix.  And WG5 is supposed to operate by consensus, not 
> the tyranny of the majority.
> 
> WG5 has already made several things obsolescent/deleted this time around.  I 
> fully expect us to consider making more things obsolescent next time.  Maybe 
> even delete some things, though that makes little difference to most vendors 
> other than the wording of the warning message.
> 
> Cheers,
> -- 
> .............Malcolm Cohen, NAG Oxford/Tokyo. 
> 
> _______________________________________________
> 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