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

[Steve Lionel]

I had not thought earlier about the attribute statements, but I see no text
in the standard that allows a repeated attribute that way - I read C814 as
prohibiting it. The text regarding override is specific to the type
declaration statement.

Steve

On Thu, Feb 23, 2017 at 11:06 AM, Clune, Thomas L. (GSFC-6101) <
thomas.l.clune at nasa.gov> wrote:

>
> On Feb 23, 2017, at 9:58 AM, Bill Long <longb at cray.com> wrote:
>
>
> 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.
>
>
> Agreed.  Also, though perhaps I?m misunderstanding Malcolm?s intent, I
> think those are also useful when working with an automatic code generator.
>   It helps to avoid the 132 character limit if attributes are on separate
> lines and variable names get long:
>
> REAL(kind=REAL32) :: <long-variable-name>
> DIMENSION :: <long-variable-name>(:,:,:)
> ALLOCATABLE :: <long-variable-name>
>
> Though, I think the proper fix here is to allow lines to be much longer
> than 132 characters.   (I know, any upper limit will be too small, but
> O(1000) would solve most preprocessing/code-generation issues I?ve
> encountered.)
>
> - Tom
>
>
>
> 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
>
>
>

-- 
.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170223/ff290bcf/attachment.html