Allow derived type components to have target attribute

[cmacmackin]

Currently the target attribute is not allowable for derived type-components. Thus, the only way to return a pointer to a component is either to declare it as a pointer itself (with all the extra work required for manual memory management) or by ensuring that the entire derived type variable itself has attribute target.

There have been times when I've wanted an accessor type-bound procedure to return a pointer to a component which takes up a large amount of memory, to avoid having to make a copy of it. Currently the only way to do this is by making that component a pointer itself, which introduces risks of memory leaks. It would be safer if I could just declare that component to have attribute target. Is there any particular reason this can't be done?

[FortranFan]

@cmacmackin good question! You may be interested in reading this response from several years ago on comp.lang.fortran: I'm yet to see a better explanation!

[cmacmackin]

Thanks for the link. I'm still not convinced that this is a good reason. If necessary, the compiler can simply enforce that the entire object be a target if a component has that attribute, surely?

[FortranFan]

Thanks for the link. I'm still not convinced that this is a good reason. If necessary, the compiler can simply enforce that the entire object be a target if a component has that attribute, surely?

Yes, surely I think too.

Fortran 2008, for example, introduced the feature, "A pointer dummy argument with intent in may be argument associated with a non-pointer actual argument with the target attribute. During the execution of the procedure it is pointer associated with the actual argument" known colloquially as "automatic pointer targetting" or auto-targetting which, if I'm not mistaken, complemented a previous mod (Fortran 2003?) where an actual argument without the TARGET attribute can be used with a dummy argument with one. I think what you suggest can loosely be placed in these categories..

Objections for such matters are often attributed to the invisible/indeterminable/intangible compiler benefits or lack thereof with optimization. But once the standard is modified to permit an erstwhile abomination, few bat an eyelid in objection!

[difference-scheme]

Thumbs up, for this proposal. This is something I really miss. In my opinion it is an irregularity of the language to allow something like real, dimension(:), allocatable, target :: array while prohibiting

type :: wrapped
   real, dimension(:), allocatable, target :: array
end type wrapped

After all, allocatables were allowed to be used in derived types by Fortran 2003 because of their many advantages (regarding safety, and automatic memory management). But we still can't point to them and thus have to use pointers again, making that whole point moot. This needs to be fixed as soon as possible (i.e. in the upcoming standard).

[aradi]

You can point to the allocatable component in the derived type:

module testmod
  implicit none

  type :: target_t
    integer, allocatable :: array(:)
  end type target_t
  
end module testmod

program testprog
  use testmod
  implicit none

  type(target_t), target :: instance
  integer, pointer :: ptr(:)

  instance%array = [1, 2, 3]
  ptr => instance%array
  print *, ptr

end program testprog

You just have to make sure, that the instance of the containing derived type has the target attribute.

I think, a derived type is an "inseparable" unit. Whenever you have one component of it in the memory, all the other components must be there as well. Therefore, the constraints a target attribute puts on a specific component, would have to be applied to all of them. To me, it is more logical then to specify the target attribute for the entire derived type instead for its components, as it is now.

[difference-scheme]

I see. They obviously followed a different philosophy on this one. Thanks for pointing this out.