[J3] sequence type equality
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...
More information about the J3