[J3] [EXTERNAL] Private enumerators

[Van Snyder]

On Fri, 2019-10-25 at 14:25 -0400, Reuben D. Budiardja via J3 wrote:
> Hello,
> 
> On 10/19/2019 01:37 PM, Van Snyder via J3 wrote:
> > Gary objected to private enumerators.
> > 
> > Access specs control access to identifiers, not objects.
> > 
> > He didn't like the possibility that one might be able to get the value
> > of an enumerator for which the module did not publish the name, using,
> > for example, INT(foo)+1 or foo%next().
> 
> I share the concern regarding access to private enumerators. Being able 
> to get the ordinal value of a private enumerator with NEXT() and turn it 
> back using the constructor seems to defeat the point of the enumerator 
> being private, and therefore a vulnerability.

If typed enumerators had been class (1) names, as BIND(C) enumerators
are, would you have objected to <access-spec> for them?  Do you object
to <access-spec> for BIND(C) enumerators?

If you have a public generic interface (or binding) and some (or all) of
the specific procedures (or bindings) are private, the private ones can
still be invoked.  Is that a problem?

> For example, suppose enumerators are being used to identify some state, 
> then being able to iterate over the private enumerators with foo%next(), 
> one can deduce how many (internal) states there are, and perhaps use 
> this state as argument, etc, introducing vulnerability.
> 
> I think it also defies "regular user's" expectation. I understand that 
> we say ENUM is not derived type and enumerators are not component, but 
> some similarities hold. With PRIVATE component, there is no access to 
> the name or value of the component outside the module unless explicitly 
> given,

If a private component appears after (or before) an array component, the
private component can be accessed by using out-of-bounds subscripts.

That's non-conforming.  It wouldn't be difficult to make reference to
NEXT(X) non-conforming if NEXT(X) is a private enumerator, but what if
NEXT(NEXT(X)) isn't private?

> e.g. via getter and setter subroutines in the module. With ENUM 
> as proposed, this is effectively provided and there is no way to disable it.
> 
> I was thinking perhaps a solution is to require that all private 
> enumerators to be defined after the public one, so that the ordinal 
> values for private enumerators are always higher than the public one. 
> Then, the requirements could be that NEXT() inside the module would 
> traverse all the enumerators, while outside the module would only 
> traverse the public enumerators. The same thing with LAST().
> 
> Some examples:
> 
> Example 1:
> 
> enum, public :: color
>    enumerator, public  :: red, green
>    enumerator, private :: purple   ! <-- compile error,
>                                    ! require all private after public
>    enumerator, public  :: blue
> end enum
> 
> 
> Example 2:
> 
> module enum_def
> 
>    enum, public :: color
>      enumerator :: red, green, blue
>      enumerator, private :: purple, black
>    end enum color
> 
> ...
> 
>    type(color) :: my_car = color%blue
>    my_car%last !-- would give "black"
>    my_car = my_car%next() !-- would give purple
> 
> end module enum_de
> 
> 
> module my_object
> 
>    use enum_def
> ...
>    type(color) :: my_house = color%green
>    my_house%last !-- would give "blue" since this is
>                  !   the last of the public enumerator
> 
>    my_house = my_house%next()  !-- would give blue
>    my_house = my_house%next()  !-- ERROR terminated
> 
> end module my_object
> 
> 
> End examples.
> 
> 
> I would be interested in feedback.
> 
> Best,
> Reuben
>