Overload the operator(=), to interface the assign and associate functions

[Ian Giestas Pauli]

Why not overload the operator(=) instead using subroutines like assign and associate?
[Why did you choose this way? (I'm curious if I can help...)]

integer :: numb
type(Var) :: val
numb = 1
val = numb ! Eq: call assign(val, numb)
numb = val ! Eq: call assign(numb, val)

operator overloading

interface operator(=)
    module procedure assign_X_to_Y
    (...)
end interface

[Nick Papior]

Yes, I thought about this (and some of my first iterations did this). But there are numerous problems with fortran in this approach.

The primary reason behind using routines is that one cannot notify the user about erroneous variable retrieval, i.e.:

logical :: bool
real :: float
type(var) :: var
call assign(var, 0.1)
bool = var
float = var

It is clear in the last line, but you cannot figure out whether it is doing it correctly in the bool = var case. Hence I think it is cleaner to stick to one approach. Sure, the user may not request whether it succeeded, but essentially they should ;)

Secondly, one cannot overload the => operator which forces you to only overload = with the above deficiency.

[Nick Papior]

Ok, you could notify the user via try-catch implementations, but this is beyond the scope of this library.

[Ian Giestas Pauli]

In this case why not perform a implicit conversion? in bool = var
the assignment function sees that var contains a 'float' different than zero and sets bool (intrinsic logical) as .true.?
The problem of the operator(=>) overloading, may be solved by using a custom one, perhaps something like:
val = .ref. target ! equivalent to call associate(val, target)

[Nick Papior]

I have to say that I don't particularly like this. :)

Another problem is how to handle var = float. Should it nullify or deallocate the internal data?

Now there can always be standards for taking care of every situation. But I don't particularly like any of the things.
If one wishes to have overloaded operators one can easily generate them and include them.

[Nick Papior]

I am gonna close this issue for now. :)