On 8/1/2017 11:46 AM, Vipul Parekh wrote:
> However, I suggest the matter be considered and at least discussed a
> bit further for a possible enhancement i.e., why not revise the very
> definition in the standard for "dynamic type" to also include type
> parameters?
>
> Instead of immediately dismissing it as "no, that is not possible",
> can readers consider a thought exercise where, say, the "dynamic type"
> is defined as "type and type parameters of a data entity at a
> particular point during execution of a program"? Will this not help
> realize some simplification to language semantics as well as bring
> some additional value for coders? The latter because it will then be
> aligned, IMO, with coders' intuition on what constitutes a dynamic
> type in relevant situations such as deallocation and finalization,
> procedure binding, etc.
I would not be in favor of redefining dynamic type to include type
parameters, not the least reason for which is that it would make
CHARACTER(10) not the same dynamic type as CHARACTER(20), which would be
chaos for the language. The standard is consistent in its use of "type
and type parameters" where it matters. I'm leaning towards a minimal
edit to the description of SAME_TYPE_AS, as I worry about unintended
side-effects of a larger change.
There are quite a few places in the language where you have to "grok"
the entire standard in order to make sense of things, largely because we
hate saying a thing in more than one place. Implementers generally get
this type and kind thing right - like Malcolm, I am not astonished that
the unusual definition of SAME_TYPE_AS eluded at least one team. I know
that I've made similar errors in reading over the years.
Steve
|