[J3] Letter ballot #38 is overdue, please vote ASAP

[Robert Corbett]

When people checked their implementations, all of them reported that their implementations ignored default initializations when determining type equivalence.  If it is a violation of common sense, it is one that went unnoticed for eighteen years.

I do not find default initialization to fit the mold of an attribute.  If it is an attribute, it is unlike any of the other attributes.  If we choose the current interpretation, perhaps we need to add a definition for the term attribute to the standard.

Robert Corbett

> On Jan 28, 2022, at 12:44 AM, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> 
> Hi folks,
>  
> Sorry I’ve been busy and not chased this up. Any votes that arrive before I next have a chance to work on it (early next week) will be counted.
>  
> Please vote now!
>  
> Steve has already voted for me.
>  
> On F18/025, I do have some comments.
> Robert argued that the restriction was undesirable because some checks were not possible at compile time, because users can provide incorrect interface blocks. Well, if we’re letting people have incorrect interface blocks (i.e. they are lying to the compiler) to evade the restriction, they can just describe an impure procedure as PURE, and thus escape *all* the purity requirements. The fact that interface blocks cannot be checked at compile time does not make the purity requirements less useful, and is just completely immaterial to the question at hand.
> The question boils down to whether two types that behave differently are “the same type”. In computer science, types that behave differently are not the same type. Did we intend to make a “type equality” rule that violates both computer science and common sense? The evidence available, including the ambiguity of the current wording, would suggest not.
>  
> Cheers,
> --
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20220128/8e90d40e/attachment.htm>