[J3] Elemental type-bound functions not useful

[Van Snyder]

On Sun, 2021-03-28 at 21:03 -0400, Vipul Parekh via J3 wrote:
> On Sun, Mar 28, 2021 at 7:12 PM Van Snyder via J3 <
> j3 at mailman.j3-fortran.org> wrote:
> > .. This makes elemental type-bound functions not really useful
> > because in a type extension, the result of the type-bound function
> > is still of the declared type.
> > 
> > Did I miss something that makes them useful?
> > 
> > Is there something that can be done to make them useful?
> > 
> > 
> 
> What about the *simpler* use cases?  ELEMENTAL proves both convenient
> and performant is such scenarios:

The cases where the situation is suboptimal are where the result is of
the same declared as the arguments. Since the passed-object dummy
argument has to be polymorphic, it can be an extension of the declared
type. But the result can't be of the same dynamic type as the argument.
>    type :: t
>       ..
>    contains
>       private      ..
>       procedure :: assign_t
>       procedure :: is_equal_t
>       generic, public :: assignment(=) => assign_t
>       generic, public :: operator(==) => is_equal_t 
>    end type
> contains
>    elemental subroutine assign_t( lhs, rhs )
>       class(t), intent(inout) :: lhs
>       type(t), intent(in)     :: rhs
>       ..
>    end subroutine
>    elemental function is_equal_t( lhs, rhs ) result(r)
>       class(t), intent(in) :: lhs
>       type(t), intent(in)  :: rhs
>       logical :: r
>       ..
> > When OO was being developed, there were proposals for CLASSOF and
> > TYPEOF declarations, to specify that some entity had the same class
> > or type as another. Those proposals failed.
>  Well, these 2 have made it into Fortran 202X and are listed in
> Fortran 21-007.  Though I personally seriously doubt their value and
> would prefer them withdrawn until 202Y until when the work toward
> Generics has been studied better.  I don't see how these 2 can help
> with ELEMENTAL.  
> 
> 
> > ..
> > Is it absolutely necessary for a passed-object dummy argument to be
> > polymorphic? An alternative is to require that one that does not
> > have a polymorphic passed-object dummy argument is overridden in
> > extensions. ..
> 
> See my proposal at the Tokyo meeting m219: 
> https://j3-fortran.org/doc/year/19/19-186.txt toward the option to
> derive an inextensible derived type in Fortran   My peers and senior
> technical leads and computational technology managers in industry
> find it to be a major concern every user derived type in Fortran is
> an extensible type at present.  Should an option be introduced
> (perhaps a TYPE attribute of SEALED), the passed dummy argument of
> said type can no longer be polymorphic, it has to be TYPE instead of
> CLASS.
> The ability for users to author inextensible derived types can
> provide several benefits.  This helps us greatly with reduced program
> vulnerability.  There is also the potential for further compiler
> optimizations knowing the passed-object is nonpolymorphic with
> inextensible types.  And it opens up such types for additional
> elemental operations where the function result attributes are those
> currently prohibited e.g., ALLOCATABLE.
> Vipul Parekh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210328/06725172/attachment-0001.htm>