https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98498
Bug ID: 98498
Summary: Interp request: defined operators and unlimited
polymorphic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: pault at gcc dot gnu.org
Target Milestone: ---
It looks as if gfortran is standard defying;
J3/yy-nnn
To: J3 Members
From: Steve Lionel
Subject: F2018 interp: Extending intrinsic operator with class(*) dummies
Date: 01-Jan-2021
----------------------------------------------------------------------
NUMBER: F08/ ! /interp assigns number after submission
TITLE: Extending intrinsic operator with class(*) dummies
KEYWORDS: unlimited polymorphic, defined operator, intrinsic operator
DEFECT TYPE: ! /interp assigns
STATUS: J3 consideration in progress
QUESTION:
Consider the following program (created by Paul Richard Thomas):
MODULE mytypes
IMPLICIT none
TYPE pvar
character(len=20) :: name
integer :: level
end TYPE pvar
interface operator (==)
module procedure pvar_eq
end interface
contains
function pvar_eq(a,b)
implicit none
class(*), intent(in) ::a,b
logical ::pvar_eq
if (.not. same_type_as (a, b)) then
pvar_eq = .false.
return
end if
select type (a)
type is (pvar)
select type (b)
type is (pvar)
print *, "a & b are type pvar"
if((a%level.eq. b%level) .and. (a%name .eq. b%name)) then !A
pvar_eq = .true.
else
pvar_eq = .false.
end if
end select
class default
print *, "class default: returning false"
pvar_eq = .false.
end select
end function pvar_eq
end MODULE mytypes
program test_eq
use mytypes
implicit none
type(pvar) x, y
x = pvar('test 1', 100)
y = pvar('test 1', 100)
write(*, *) x == y
x = pvar('test 1', 100)
y = pvar('test 2', 100)
write(*, *) x == y
end program test_eq
The intrinsic equality operator is extended with a function where both
dummy arguments are unlimited polymorphic. Three compilers accept this;
two use the extension for comparisons of any type, such as the one between
two integers at "!A" - the other applies the intrinsic meaning to the
integer comparison.
15.4.3.4.2p1 (Defined operation) says:
"If the operator is an intrinsic-operator (R608), the number of dummy
arguments shall be consistent with the intrinsic uses of that operator,
and the types, kind type parameters, or ranks of the dummy arguments
shall differ from those required for the intrinsic operation (10.1.5)."
The phrase "shall differ" here is not the same as in 15.4.3.4.5
(Restrictions on generic declarations) which instead talks about TKR
compatibility and the ability to "distinguish" dummy arguments.
"C1511 Within the scope of a generic operator, if two procedures with
that identifier have the same number of arguments, one shall have a
dummy argument that corresponds by position in the argument list to a
dummy argument of the other that is distinguishable from it."
Was it intended that the standard treat extending intrinsic operators in
a different manner than other generic interfaces? If so, how should this
program be interpreted?
ANSWER:
No, such a treatment was not intended. Extending a generic intrinsic
operator follows the same rules as other generic extensions. The
example program violates C1511 in that the unlimited polymorphic
dummy arguments are not distinguishable from arguments of any type
for which the intrinsic operator is valid (Table 10.2). Consider also
Note 1 in 10.1.6.1 (Defined Operations > Definitions) says:
"An intrinsic operator can be used as the operator in a defined operation.
In such a case, the generic properties of the operator are extended"
An edit is proposed to correct the deficiency.
EDITS to 18-007r1:
[295:10, 15.4.3.4.2 (Defined operations)]
In the last sentence, remove the text "types, kind type parameters, or
ranks of the" and replace "replace "differ from" with "be distinguishable
from", with "distinguishable" linked to 15.4.3.4.5 (Restrictions on
generic declarations). The sentence now reads:
"If the operator is an intrinsic-operator (R608), the number of dummy
arguments shall be consistent with the intrinsic uses of that operator,
and the dummy arguments shall be distinguishable from those required
for the intrinsic operation (10.1.5)."
SUBMITTED BY: Steve Lionel
HISTORY: yy-nnn m223 F08/nnnn submitted
----------------------------------------------------------------------
