Restricting the extensibility of derived types

[OP1]

Is there a way to prevent the extensibility of derived types? I am thinking about something like this:

MODULE M
IMPLICIT NONE
TYPE, RESTRICTED :: T1
END TYPE T1
TYPE, EXTENDS(T1), RESTRICTED :: T1A
END TYPE T1A
TYPE, EXTENDS(T1) :: T1B
END TYPE T1B
END MODULE M

where the RESTRICTED attribute would limit extensibility of a type to the scope of the module. In the code example, only type T1B would be extensible outside the module.

Types that would be 'restricted' would still be usable (based on their public/private access properties) in units that use M, that is, one would still be able to declare a variable of those types. But they would not be extensible.

There is a substantial value for doing this for library work (and code safety). If there is an interest in this, can this request be forwarded to the standard committee?

[Steve_Lionel]

You can prevent a type from being extended by making it a SEQUENCE type or an interoperable (BIND(C)) type, but there isn't a way to limit extensibility to your own module. Have you considered private components? It is not clear to me how you would use this.

[OP1]

Using private components would mean that these components are not accessible outside of the module.

The desired outcome of the suggestion above is to create a class completely encapsulated in a module. A user of that module would be able to declare variables of the types defined in that module (depending on public/private attributes set for those types, of course), and at the same time maintain access to the type components and the type-bound procedures (again, depending on public/private attributes) of those types.

However, the user would not be able to extend any of those 'restricted' types. This would restrict the user's ability to pass a custom extension of the class as argument to a procedure which accepts a polymorphic argument of that class; more precisely, this would eliminate the risk of executing code contained in an overridden binding defined by a user extension of the class.

[Steve_Lionel]

Still not understanding. In the case you mention, the user's extended components would not be visible to the procedure which would see only the components in the declared type. (I discuss this in Doctor Fortran in "Not My TYPE" - Doctor Fortran (stevelionel.com) )You can also specify that a type-bound procedure is NON_OVERRIDABLE.

Can you put together a code outline of the situation you want to avoid?

[OP1]

The code below may help answer your question.

MODULE M
IMPLICIT NONE
TYPE, ABSTRACT :: T0
    CONTAINS
        PROCEDURE(T0_PROC),DEFERRED :: PROC
END TYPE T0
TYPE :: T1
    CONTAINS
        PROCEDURE :: PROC => T1_PROC
END TYPE T1
TYPE, EXTENDS(T1) :: T2
    CONTAINS
        PROCEDURE, NON_OVERRIDABLE :: PROC => T2_PROC
END TYPE T2
ABSTRACT INTERFACE
    SUBROUTINE T0_PROC(SELF)
    IMPORT :: T0
    IMPLICIT NONE
    CLASS(T0) :: SELF
    END SUBROUTINE T0_PROC
END INTERFACE
INTERFACE
    MODULE SUBROUTINE T1_PROC(SELF)
    IMPLICIT NONE
    CLASS(T1) :: SELF
    END SUBROUTINE T1_PROC
    MODULE SUBROUTINE T2_PROC(SELF)
    IMPLICIT NONE
    CLASS(T2) :: SELF
    END SUBROUTINE T2_PROC
END INTERFACE
END MODULE M

The requirements of the class design are:

1. The user needs access to all non-abstract types in M (their components and their procedures) to declare variables of those types;

2. The user cannot extend the types.

3. If (2) is not achievable, the user is prevented from overriding any of the type-bound procedures.

It sounds to me that you can only prevent the overriding of the PROC binding for the 'deepest' types in the class (T2 in this example).

I am not sure that there is a convenient way to prevent the user from overriding T1%PROC .

[IanH]

Separate to any discussion of the value of such a language feature, make the type bound procedures private and provide boring normal not-type-bound procedures (which just forward to the type bound procedures) for your clients to call.

[OP1]

IanH, this is an interesting thought - it certainly solves the problem. But it will also become rather unwieldy when you have 1000s (if not more) of such procedures... I wish there was a better way.

[FortranFan · Accepted solution]

@OP1 wrote:
.. There is a substantial value for doing this for library work (and code safety). If there is an interest in this, can this request be forwarded to the standard committee?

@OP1 ,

A couple of your recent posts also have to do with general Fortran language.

For such cases, in case you are aware, you may also want to post them at the Fortran Discourse site for broader community feedback on your inquiries: https://fortran-lang.discourse.group/

Also, for suggestions or proposals toward the Fortran standard, please also consider the GitHub site in case you have not already tried reviewing the items there: https://github.com/j3-fortran/fortran_proposals 

Additionally on the topic of your original post here, please take a look at the following and post your comments and as you deem appropriate, indicate your support with an emoticon:

https://github.com/j3-fortran/fortran_proposals/issues/37

[OP1]

@FortranFan thanks a lot for the links! I am glad to see I am not the only one who thinks 'locking down type extensibility' is a valuable suggestion.

Also, I was not aware of the GitHub repository to submit proposals to the standard committee, this is great!