Use of . instead of % for components of derived types

[Andrew_Smith]

I discovered by a mistake that IVF supports "." to seperate components of derived types.

e.g. Fred.isActive instead of Fred%isActive

It looks better than % because it gives more visual seperation without having to resort to putting spaces around %.

It also makes copy/paste of code from other languages easier.

How portable is the use of "." seperator?

Andy

[Steven_L_Intel1]

Not very. Don't use it in new code. We support it because DEC Fortran supported STRUCTURE/RECORD with a dot separator back to 1988, before Fortran 90 had settled on a syntax. Our compiler treats these, mostly. as interchangeable but I know others that do not.

Here's my rule: if standard Fortran offers an equivalent syntax, use the standard syntax and not an extension, no matter how much you may like the extension. It will save you grief later.

[TimP]

Quoting - Steve Lionel (Intel)

Not very. Don't use it in new code. We support it because DEC Fortran supported STRUCTURE/RECORD with a dot separator back to 1988, before Fortran 90 had settled on a syntax. Our compiler treats these, mostly. as interchangeable but I know others that do not.

Here's my rule: if standard Fortran offers an equivalent syntax, use the standard syntax and not an extension, no matter how much you may like the extension. It will save you grief later.

The . notation was never portable enough that I ever saw it used, even before the % version was available widely enough. The Fortran committees apparently went over all the pros and cons when they set up derived types as the way to implement those DEC extensions.

A slight digression in that vein: ifort supports just about all known versions of the loc() intrinsic, but there is no warning available when not using the wordier standard version. The warnings I get in my test case are only things which every known compiler supports (tabs, and mandatory warning when using .f format), while the real portability problem isn't flagged. Maybe I'll submit an issue report. I suppose that's an f2003 completeness issue, but I'd like to quote Steve's advice.

[Steven_L_Intel1]

Tim,

I'd like to see an example where non-standard loc is not flagged. Here's what I see:

loc.f90(2): warning #7416: Fortran 2003 does not allow this intrinsic procedure.
[LOC]
print *, loc(i)
---------^
loc.f90(3): warning #7416: Fortran 2003 does not allow this intrinsic procedure.
[%%LOC]
print *, %loc(i)
----------^

(Hmm - %%LOC? That's amusing...)

I'd like to see us allow some granularity of standards warnings - VAX Fortran had a "source_form" option you could turn off to disable warnings for tab source form, and perhaps to disable warnings for deprecated features.

[TimP]

Quoting - Steve Lionel (Intel)

Tim,

I'd like to see an example where non-standard loc is not flagged. Here's what I see:

loc.f90(2): warning #7416: Fortran 2003 does not allow this intrinsic procedure.
[LOC]
print *, loc(i)
---------^
loc.f90(3): warning #7416: Fortran 2003 does not allow this intrinsic procedure.
[%%LOC]
print *, %loc(i)
----------^

(Hmm - %%LOC? That's amusing...)

I'd like to see us allow some granularity of standards warnings - VAX Fortran had a "source_form" option you could turn off to disable warnings for tab source form, and perhaps to disable warnings for deprecated features.

I filed issue 526989. c_loc is accepted, works fine, with no warning,when the mandatory TARGET attribute is omitted. A nit pick; from the warnings you quote, one would not guess that the non-allowance is due to legacy spelling, not to non-support of the relevant f2003 syntax.

Yes, granularity would be desirable. People tend to turn the warnings off entirely when they shouldn't, and don't want to make the effort to turn them off individually.

[Steven_L_Intel1]

Tim,

I do not agree that the issue is spelling. C_LOC is very different in definition than LOC or %LOC. LOC and %LOC return an address-sized integer while C_LOC, which is defined in intrinsic module ISO_C_BINDING, returns a value of derived type C_PTR. These are NOT interchangeable even though the binary value is the same.

The compiler is not required to issue standards warnings for violation of the rules for C_LOC.