is it possible to create += to mimic C

[Brian_Murphy]

Is it possible to create += to mimic C.  If not, is this something planned for a future standard?

INTERFACE ASSIGNMENT (+=)   ????

[Steve_Lionel]

No and no. The standards committee has discussed += and -= but decided that it is just "syntactic sugar" that doesn't add any capabilities. 

[Brian_Murphy]

Well, you can't argue with that logic.  I guess the only real gains would be cleaner code and maybe prevent a bug or two, which I suppose was the motivation for the creators of C.

What's your opinion on it, Steve?

[Steve_Lionel]

I don't think it's worth the effort to add it to the language, though I have no objection to the feature itself. I often say that every change to the standard has a cost, in terms of time spent defining the feature and vendors time implementing it. I weigh such costs against other things we could be doing instead, and for something like this, it loses.

We often see people saying "language X has this feature, why not add it to Fortran?" If the feature truly enhances the development of scientific and engineering applications, which is Fortran's reason for being, then it should be seriously considered. But if it's just yet another way of doing something Fortran already has, and I'd disagree that it prevents bugs, then I'd rather be working on something else (such as conditional expressions, which I am working on.)

[andrew_4619]

"I guess the only real gains would be cleaner code and maybe prevent a bug or two"

I don't get that argument at all. I can't see any real situation where the lack of a += operator would lead to bugs. "Cleaner" is very subjective!

[FortranFan]

With the technical/software solutions with your business, if you're seriously committed to Fortran, you may want to consider engaging and discussing closely and collaborating with the developing Fortran 'community' online at sites such as GitHub:

• See this site for community proposals toward enhancing the Fortran language: https://github.com/j3-fortran/fortran_proposals
• See a suggestion at this proposal site which is rather close to what have posted here: https://github.com/j3-fortran/fortran_proposals/issues/113
• Also, see also https://fortran-lang.org/
• And the Discourse section with other interested Fortranners at that site: https://fortran-lang.discourse.group/
• For what can be seen as essentially Fortran language discussions, these links are increasingly better suited than this forum.

[avinashs]

Probably should not be allowed for the same reason that overloading ** is not allowed in C++ to mimic the power function. Overloading by definition is for existing operators so unless Fortran adds += to its current list of operators, += would remain unavailable for that purpose (as would ++, -- etc.).

Interestingly, I have seen the Bitwise exclusive OR operator (^) being overloaded with the power function in C++. C++ does not care whether the overloading actually does what it is supposed to do and ^ is a convenient choice since it is the analog of ** in VB.net and VBA. Don't know if Fortran does any logical checks either.

[Steve_Lionel]

Fortran allows extending intrinsic operators but, like any generic extension, the arguments (operands) can't match an existing definition. So while you are free to have INTERFACE OPERATOR (+), you can't use this to replace intrinsic addition. Similarly if you have INTERFACE OPERATOR (.OR.), you can define this on non-LOGICAL types, but not on two LOGICALs. Fortran doesn't care what your extended routine does.

This caused me to wonder what Intel Fortran does for cases where it already extends certain operators, such as .OR. with integer arguments (see Doctor Fortran in “To .EQV. or to .NEQV., that is the question”, or “It’s only LOGICAL”)

So I tried this:

module myfuncs
contains
function myextor (a,b)
integer :: myextor
integer, intent(in) :: a,b
myextor = a + b
end function myextor
end module myfuncs

program test
use myfuncs
implicit none
!interface operator (.OR.)
!  module procedure :: myextor
!  end interface
  
print *, (3 .OR. 6)
end program test

I was pleased to see that, even though ifort provides a definition for 3 .OR. 6, it let me replace that with my own function. With the generic interface enabled, the program prints 9, with it disabled, it prints 7.