Closed sethrj closed 5 years ago
Definitely for it, it gives users of the tool more control.
This could help with the subroutine/function "generic" conflict, but it could also cause failures if the subroutine with the "optional" output parameter conflicts with another subroutine:
class Foo {
int myvalue_;
public:
int myvalue() const { return myvalue_; }
void myvalue(int new_value) { myvalue_ = new_value; }
};
The getter/setter overload is idiomatic of C++ standard library; so perhaps we could make the parameter not optional if it's a const
method with no input parameters? That seems pretty sensible and would allow us to differentiate from:
status_t calculate();
Couldn’t you use an interface block for the case of conflicting function names?
INTERFACE myvalue
SUBROUTINE myvalue_setter(in_value)
integer, intent(in) :: in_value
END SUBROUTINE
SUBROUTINE myvalue_getter(out_value)
integer, intent(out) :: out_value
END SUBROUTINE
END INTERFACE
@tjfulle I didn't realize Fortran's module interfaces would allow multiple subroutines where the only difference is the intent. This might not be too bad then.
@sethrj, I’m not sure that the intent can distinguish one type from another and allow overloading. I think I jumped the gun.
HDF5 and other C apps often use error codes for return values. It's also not uncommon in C++ code to return a value that won't necessarily be used (e.g.
std::map.insert
).I propose a new
%feature("fortran:subroutine") funcname;
that will convert a function's return type to anintent(out), optional
-qualified dummy variable, turning the function into a subroutine.