[J3] Clarification on F18/017

[Ondřej Čertík]

Hi Malcolm,

Thank you for your partial answer and we are looking forward for the full answer. Over the weekend is fine. That would give us enough time to discuss.

Cheers,
Ondrej

On Thu, Jun 4, 2020, at 5:47 PM, Malcolm Cohen via J3 wrote:
> Hi Ondrej,
> 
> 
> Thanks for your question. I can do a partial answer immediately, but a 
> full one requires analysis I probably won’t have time to do today, as I 
> am rather snowed under and have urgent deadlines to attend to. I’ll do 
> the full analysis asap, but could be over the weekend.
> 
> 
> Re 1, yes it definitely precludes multiple finalization of A.
> 
> (This is where I need to study the program carefully to see which 
> output combinations are allowed.)
> 
> 
> Re 2, that is correct, no question about it.
> 
> 
> I’ll get back to you as soon as I can on precisely which ordering are 
> permitted, unfortunately now I really have to rush to prepare for an 
> urgent meeting.
> 
> 
> Cheers,
> 
> -- 
> 
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
> 
> 
> *From:* J3 <j3-bounces at mailman.j3-fortran.org> *On Behalf Of *Ond?ej 
> ?ertik via J3
> *Sent:* Friday, June 5, 2020 3:49 AM
> *To:* J3 Mailinglist <j3 at mailman.j3-fortran.org>
> *Cc:* Ondřej Čertík <ondrej at certik.us>
> *Subject:* [J3] Clarification on F18/017
> 
> 
> Hi,
> 
> We have a question for the interpretation F18/017. As it was submitted 
> for vote, and if the edits are done to the standard, what is the 
> expected result of the program that I am attaching below? See the issue 
> https://github.com/j3-fortran/fortran_proposals/issues/146 for more 
> context and background.
> 
> 1. Our understanding is that the new standard would preclude multiple 
> finalization of A (which is good), but would allow the compiler to 
> implement any of CABP, CBAP, and CBPA call orders. 
> 
> 2. A program could force CABP by explicitly deallocating the 
> allocatable component in the final procedure for the containing object.
> 
> Is both 1. and 2. correct?
> 
> Thanks,
> Ondrej
> 
> ----------------
> 
> module child_type
> 
> implicit none
> private
> 
> type :: objectA
> contains
> final :: finalize_objectA
> end type
> 
> type :: objectB
> contains
> final :: finalize_objectB
> end type
> 
> type :: parent
> contains
> final :: finalize_parent
> end type
> 
> type, extends(parent), public :: child
> type(objectA), allocatable :: A
> type(objectB) :: B
> contains
> procedure :: init
> final :: finalize_child
> end type
> 
> contains
> 
> subroutine finalize_objectA(this)
> type(objectA), intent(inout) :: this
> write(*,'("A")',advance='no')
> end subroutine
> 
> subroutine finalize_objectB(this)
> type(objectB), intent(inout) :: this
> write(*,'("B")',advance='no')
> end subroutine
> 
> subroutine finalize_parent(this)
> type(parent), intent(inout) :: this
> write(*,'("P")',advance='no')
> end subroutine
> 
> subroutine finalize_child(this)
> type(child), intent(inout) :: this
> write(*,'("C")',advance='no')
> end subroutine
> 
> subroutine init(this)
> class(child), intent(inout) :: this
> allocate(this%A)
> end subroutine
> 
> end module
> 
> program main
> use child_type
> call run
> contains
> subroutine run
> type(child) :: c
> call c%init
> end subroutine
> end program
> 
> 
> *Disclaimer*
> 
> The Numerical Algorithms Group Ltd is a company registered in England 
> and Wales with company number 1249803. The registered office is: 
> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom. 
> Please see our Privacy Notice 
> <https://www.nag.co.uk/content/privacy-notice> for information on how 
> we process personal data and for details of how to stop or limit 
> communications from us.
> 
> This e-mail has been scanned for all viruses and malware, and may have 
> been automatically archived by Mimecast Ltd, an innovator in Software 
> as a Service (SaaS) for business.
>