[J3] sequence type equality

Richard Bleikamp richard.bleikamp at amd.com
Thu Oct 15 11:00:42 EDT 2020


Just because something is deleted in the standard does NOT mean the 
compilers stop supporting it, nor will all users rewrite their code to 
stop using it.

When a feature is obsolescent, the committee still strives to make it 
work with all new features, in a common way, that users can count on.  
Once the feature is deleted, implementations will vary :(.  Whether or 
not the vendors should force their users to fix their code to avoid 
deleted features is a discussion for a FIDS meeting with lots of beer.  
So I'm in favor of leaving obsolescent features in the standard for a 
long time (10 years), at least for features commonly used in the distant 


On 10/15/20 10:47 AM, Vipul Parekh via J3 wrote:
> [CAUTION: External Email]
> On Thu, Oct 15, 2020 at 8:22 AM Bill Long via J3 
> <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org>> wrote:
>     BIND(C) types solve the problem of interacting with C.  Modules
>     solve he problem of “same type as”.  COMMON is obsolescent and
>     better replaced by modules.   I don’t see any ue for SEQEUNCE
>     types any more, except that really old codes might have them (as
>     well as arithmetic IF and a lot of other ancient junk).   Is there
>     any use for SEQUENCE that does not already have a batter
>     alternative? ..
> How will marking SEQUENCE as Obsolescent be of any help with the 
> immediate issue at hand which is the hole indicated by Bob when it 
> comes to PURE procedures? Given the importance of PURE in modern 
> programming using Fortran, isn't really the choice here to either 
> strive to plug this hole or let the risk remain?
> Marking something as Obsolescent does not mean the feature can be 
> ignored in any real sense, right?  Meaning, the semantics and/or 
> syntax associated with such a feature can continue to have impact on 
> other existing features and also the new ones.  Fixed-form source, 
> marked as Obsolescent, is a classic example: one can see the work on 
> Conditional Expressions and the syntax for that needs to critically 
> consider the fixed-form source also.  This same aspect applies to 
> everything on the Obsolescent list.
> Until something is Deleted, all features including the Obsolescent 
> ones effectively seem to remain as "first-class" in the standard, 
> don't they!?.
> This does distress me in that the Obsolescent category seems just a 
> label in the standard.
> So now, can SEQUENCE be deleted?  Does it not appear likely ever, right!
> To do something here, like when two derived types with SEQUENCE 
> attribute be considered the same type, is the plug that can fill the 
> gap brought forth by Bob.
> None of this is to suggest SEQUENCE should not be marked as 
> Obsolescent, just that it is a separate consideration.
> Vipul Parekh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20201015/8038c327/attachment.htm>

More information about the J3 mailing list