Changing . to % to access components of derived types

21

I challenge anyone to show me a derived type member name with the . extension that cannot be used at some later time as an operator name. :wink:

22

a_1. Don’t ask me why, but a defined operator can only use letters.

R1024 defined-binary-op is . letter [ letter ] … .

1 Like
23

I stand corrected. :slight_smile: I did not remember that restriction. The point I was making, of course, was that it is not possible to know ahead of time which (alphabetic only) component names to avoid in order for the . syntax to be universally unambiguous.

24

This is just speculation, but maybe it’s because the namespaces are not expected to conflict (i.e., you can have both operator(.nabla.) and type(nabla) :: a in the same scope), and therefore there are no precedence rules. And spaces being insignificant in a fixed-form source tend to complicate things.

If numbers were allowed in user-defined operators, and you had:

Call me fixed-form source
      use my_operators, only: operator(.operate1.)
      integer :: operate = 4
      print *, 1 .operate1. 0
      end

Then the fixed-form parser could have interpreted the expression in the print statement as 1. operate 1.0… and crashed!

1 Like