[J3] [EXTERNAL] Re: USE statement – wish: permit specifying additionally the access-spec

[Van Snyder]

On Fri, 2019-11-15 at 23:04 +0000, Bill Long via J3 wrote:
> While I'm not part of the Data subgroup, I’m pretty sure that the
> design for this feature was not an oversight.  Rather, it likely had
> to do with the fact that public and private declarations are limited
> to being only in a module, whereas USE statements (often) appear
> outside modules. Sure, you could add in a constraint that the
> access-spec cannot be specified in a USE statement that is outside a
> module, but that is just one extra complication that is not needed
> with the current design. 
> 
> That said, we already permit redundant ways to specify public and
> private for many other situations. So I would not be opposed to this
> idea.  Some comment from /Data would be informative.

Another reason not to put an access-spec on a USE statement is that a
scoping unit can have more than one USE statement for the same module.
What is the effect of

  use, private :: A
  use, public :: A


> 
> Cheers,
> Bill
> 
> 
> 
> > On Nov 15, 2019, at 3:02 PM, Vipul Parekh via J3 <j3 at mailman.j3-fortran.org> wrote:
> > 
> > On Fri, Nov 15, 2019 at 11:32 AM Tobias Burnus via J3
> > <j3 at mailman.j3-fortran.org> wrote:
> >> ..
> >> I still believe that a use-stmt with access-spec is more readable than
> >> use-stmt + access-stmt, but I agree that the functionality is already
> >> covered. Hence, I think one should still (re)consider it – but with low
> >> priority.
> >> ..
> > 
> > Tobias makes a good point.
> > 
> > Is it possible to know whether there was a reason besides an oversight
> > as to why access-spec with the USE statement was not introduced in
> > Fortran 2018 itself when the deficiency with the default accessibility
> > for entities accessed from a module was addressed?
> > 
> > If this is an oversight with Fortran 2018, then how can one exhort J3
> > but importantly WG5 to include this and other such "Features that
> > address deficiencies and discrepancies" on the Fortran 202X work-list?
> > 
> > Thanks,
> > Vipul Parekh
> 
> Bill Long                                                                       longb at cray.com
> Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
> Bioinformatics Software Development                      fax:  651-605-9143
> Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425
> 
> 
>