Reduced verbosity for allocate/select type

[jacobwilliams]

I seem to encounter this sort of thing a lot:

class(abs_class),allocatable :: my_class

allocate( specific :: my_class )
select type (my_class)
class is (specific)
  !... now can access specific my_class members...
end select 

It would be nice to combine the allocate/select type/class is into one line. If you're going to allocate a class, and then immediately do something with it, the amount of code here seems excessive.

I'm not sure what the syntax would look like.

[nncarlson]

I find this to be a nuisance too. I have no suggestions to offer on a new combined syntax, but have found the following strategy to be less obnoxious:

class(abs_class),allocatable :: my_class
type(specific),allocatable :: my_specific

allocate( my_specific)
  !... do what you want with specific type members...
call move_alloc(my_specific, my_class)

[jacobwilliams]

@nncarlson Nice! From 5 lines to 4.

I was thinking something like this (3 lines):

class(abs_class),allocatable :: my_class

something allocate( specific :: my_class )
  !... now can access specific my_class members...
end something

[FortranFan]

@jacobwilliams wrote:

..
It would be nice to combine the allocate/select type/class is into one line. If you're going to allocate a class, and then immediately do something with it, the amount of code here seems excessive.

I'm not sure what the syntax would look like.

@jacobwilliams , you may note inquiries such as yours have appeared on many a forum and the 'canonical' feedback to all those hapless Fortranners, often newbies dabbling with OO in Fortran, is their choices per the language standard are mostly verbose, particularly when it comes to employing polymorphism in their actual code. That to eschew polymorphism via better OO design and analysis (OOA and OOD) of one's code is what they should pursue if they seek reduced verbosity. Such feedback has always bothered me quite a bit even though I have on occasions suggested that to forum readers for lack of anything else.

I personally think coder productivity is of paramount importance and convenient syntax (which many dismiss as 'syntactic sugar' to my great dismay) is a critical part of this. I'm inclined to place high priority on enhancements involving better syntax that can improve Fortran on the verbosity ranking. Where I work in industry there just ain't no way a team of 2 or more developers can be tasked to work using Fortran on a new project which will inevitably involve extensive utilization of object-oriented paradigm given the kind of verbose syntax on offer, especially with the managers having to keep in mind all the other limitations in Fortran when it comes to data processing.

So, with that preamble, a thought which I have always had (and toward which I was working to propose a paper for Fortran 202X until I got totally deflated after learning this past June the work-list for 202X was pretty much frozen with items that were decided several meetings earlier in Feb 2018) was to consider using angle brackets <..> (or another convenient notation) to signal 'dynamic' downcasting. Say if you could do something along the following lines:

   ...
   class(abs_class), allocatable :: my_class
   ...
   allocate ( specific :: my_class )
   ...
   ! now access specific my_class members via dynamic cast.
   call <specific>my_class%foo( .. )
   <specific>my_class%bar = ..
   ...

The basic idea of the above construct is to simply introduce a short-hand notation (and thus achieve your stated objective which is reduced verbosity) for each instance toward downcasting which a coder might do using the current standard with basic error handling such as with

   ...
   class(abs_class), allocatable :: my_class
   ...
   allocate( specific :: my_class )
   ...
   select type ( my_class )
      type is ( specific ) ! or 'class is ( specific )
          ! access specific member 'foo'
          call my_class%foo( .. )
      class default
           error stop 'No match in type-guard statement'
   end select
   select type ( my_class )
      type is ( specific ) ! or 'class is ( specific )
          ! access specific member 'bar'
          my_class%bar = ..
      class default
           error stop 'No match in type-guard statement'
   end select
   ...

The coder with <specific> downcasting option shown above achieves compactness in their code while also being forced to enter into an exception handing scenario - something per the current standard, they then tend to overlook with missing or empty class default statements anyway and not realize no block is executed and thus experience what can be considered 'silent errors' in their code.

My hope was the work toward exception handling will go on in parallel as part of Fortran 202X and a use case to handle type-guard mismatch during dynamic downcasting can get added to that work. Alas!

A forward-looking processor such as LFortran might even be able to try out the above with just their parser and provide feedback on the pros and cons?

[aradi]

I think, there are two aspects there. The first one is the access of specialized fields without having to specify select type. I usually also use the pattern as suggested @nncarlson and I don't think, that sparing just one line would be justified to introduce a new syntax. The second one, is the safety of the select type construct as brought up by @FortranFan, and that I find much more sever. Forgetting to specify a class default block can make up for hard to spot bugs.

But probably, this could be solved by a simple intrinsic subroutine as well, instead of a new syntax. This subroutine would associate a specific pointer with an abstract base class if possible, and either return an error code (as an optional argument) or stop the execution if the association was not possible.

class(abs_class), allocatable, target :: myclass
class(specific), pointer :: specificptr
integer :: error

allocate(specific :: myclass)
! Would stop the code if failing
call associate_specialization(myclass, specificptr)   
! It would be the programmers responsibility to check the content of error afterwards
call associate_specialization(myclass, specificptr, assocerror=error)