From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org  Thu Jan 21 22:11:13 2016
Return-Path: <owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www.open-std.org
Received: by www.open-std.org (Postfix, from userid 521)
	id 6B3AB358755; Thu, 21 Jan 2016 22:11:13 +0100 (CET)
Delivered-To: sc22wg5@open-std.org
Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.109])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by www.open-std.org (Postfix) with ESMTP id A3E723566C1
	for <sc22wg5@open-std.org>; Thu, 21 Jan 2016 22:11:00 +0100 (CET)
Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57])
	by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u0LLAtJk001776
	(using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128 bits) verified NO)
	for <sc22wg5@open-std.org>; Thu, 21 Jan 2016 13:10:57 -0800
Subject: Is LOCK_TYPE still not locked up?
From: Van Snyder <Van.Snyder@jpl.nasa.gov>
Reply-To: Van.Snyder@jpl.nasa.gov
To: sc22wg5 <sc22wg5@open-std.org>
Content-Type: text/plain; charset="ISO-8859-1"
Organization: Yes
Date: Thu, 21 Jan 2016 13:10:55 -0800
Message-ID: <1453410655.11277.769.camel@math.jpl.nasa.gov>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3 (2.32.3-34.el6) 
Content-Transfer-Encoding: 7bit
X-Source-Sender: Van.Snyder@jpl.nasa.gov
X-AUTH: Authorized
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

In C1305 (C1303 in 10-007r1), a named variable with a declared type of
LOCK_TYPE (Corrigendum 4 introduces "declared") shall be a coarray, and
a named variable with a noncoarray subcomponent of type LOCK_TYPE shall
be a coarray.

6.7.1.1p4 says the <source-expr> in an ALLOCATE statement cannot have a
subcomponent whose dynamic type is LOCK_TYPE.

I hope we don't allow this, but I don't see where it's prohibited:

type :: T1
end type T1

type, extends(t1) :: T2
  type(lock_type) :: L
end type T2

type :: T3
  class(t1), allocatable :: Q
end type T3

type(t3), save :: V3[*]
type(t3), allocatable :: V4[*]

allocate ( type(t2) :: v3%q )

allocate ( v4, source=v3 )

The problem (if there is one) arises because the definition of
"subcomponent" stops at allocatable components.

The declaration of V3 doesn't fall afoul of C1305 because it doesn't
have a potential subobject component of type LOCK_TYPE.

I don't think the allocation of v3%q with type(t2) violates 6.7.1.1p4
because it's not a <source-expr>.

I don't think the allocation of v4 falls afoul of 6.7.1.1p4 because v3
doesn't have a subcomponent of whose dynamic type is LOCK_TYPE.  V3 is,
however, of a type that has a potential subobject component of type
LOCK_TYPE.  Does 6.7.1.1p4 need to say that instead of "subcomponent"?
If so, we still need to do more work on Corrigendum 4.