@sblionel there suspected it wasn’t pursued because it doesn’t add new capability (i.e. syntactic sugar), and complications associated with existing /=. If you read down the thread in the mailing list, you’ll see that there is non-negligible desire/support for including a limited set of operators (+= and *=) which avoids the complication with /=.
If you want += and similar in Fortran, please post in this topic. There will be opportunity for it for F202Y.
Can you and anybody else who wants this please upvote the proposal there (click on the +1 in the top issue comment)? Currently it has only 6 upvotes. If we can show that hundreds of people want this, then we might have a case. Otherwise I would say there is just not enough support for this.
This feature really seems like a low-hanging one that will benefit Fortran users in both the short run and long run. I guess it should not be too difficult to implement. How likely is it to be added to the next Fortran standard?
A benefit of the assignment operator is avoiding typos such as
x(i,j,k) = x(i,k,j) + 1
where the LHS is not incremented by 1 because j and k are interchanged on the RHS. I have proposed adding an elemental subroutine called increment to stdlilb, so that one can write
It is easy to implement:
module procedure increment_int,increment_real_sp
end interface increment
pure elemental subroutine increment_int(i,iadd)
integer, intent(in out) :: i
integer, intent(in) :: iadd
i = i + iadd
end subroutine increment_int
pure elemental subroutine increment_real_sp(x,xadd)
real, intent(in out) :: x
real, intent(in) :: xadd
x = x + xadd
end subroutine increment_real_sp
end module m
use m, only: increment
real :: x,xvec(3)
integer :: i,ivec(3)
x = 5.2
i = 5
xvec = real([1,4,9])
print*,x,i,xvec ! 6.50000000 8 11.0000000 14.0000000 19.0000000
print*,xvec ! 12.0000000 16.0000000 22.0000000
end program main
I favor adding assignment operators, but I don’t think their absence is a big problem.
Also in addition to that, having a “rolling release” would also help to get small features like this one in.
However, I think the best way for Fortran is to actually implement features in a compiler first so that we can actually use it. And also implement translation to a subset of Fortran that compiles with other current compilers, so that one is not locked in.
One thing that I don’t know yet is how to handle these proposals: above I posted a link to LFortran where it is implemented on a branch. Obviously we probably don’t want to merge it into master. For example, what if we change our mind, etc. It could possibly be enabled with an option, but even then it requires changes to the parser, etc. If you and others have ideas how to handle theses prototypes, so that we don’t close doors for us in the future, let me know. Perhaps if there is no performance overhead, it can be enabled with an option. Otherwise it can live on a branch, or perhaps enabled with a preprocessor macro at compile time (of LFortran).