-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unused attribute #316
Comments
Good idea. Probably |
The reason it is called |
Can you show an example of this? Isn't the use case rather that a given variable can both be used and unused, depending on a preprocessor option? But it's never "maybe used" (some kind of superposition of used and unused?), it seems it is always either used or unused. |
@ivan-pi wrote Oct. 6, 2023 05:37 PM EDT:
For whatever it's worth, my firm opinion is something like "maybe_unused" does not fit in the language standard but specific processor (compiler) implementations may choose to do better to enhance the experience of their users. I think there are two parts to the underlying issue:
|
Another idea is to do what Rust does, where the compiler asks the user to prefix a variable name with "_" to avoid the unused warnings. Thanks @FortranFan for your comments. Yes indeed, compiler cooperation will be key here. |
Consider this example: module m
abstract interface
function Ifunc1(x) result(r)
integer, intent(in) :: x
integer :: r
end function
function Ifunc2(x, y) result(r)
integer, intent(in) :: x
integer, intent(in) :: y
integer :: r
end function
end interface
interface solve
module procedure solve1
module procedure solve2
module procedure solve3
end interface
contains
subroutine solve1(x, proc)
integer, intent(inout) :: x
procedure(Ifunc1) :: proc
x = proc( x )
end subroutine
subroutine solve2(x, y, proc)
integer, intent(inout) :: x
integer, intent(in) :: y
procedure(Ifunc2) :: proc
x = proc( x, y )
end subroutine
subroutine solve3(x, proc) !<-- indistinguishable from solve1
integer, intent(inout) :: x
procedure(Ifunc2) :: proc
integer :: y
y = 0
x = proc( x, y )
end subroutine
end module
Improved semantics in the language can take into account specific elements of the interface e,g., module m
abstract interface
function Ifunc1(x) result(r)
integer, intent(in) :: x
integer :: r
end function
function Ifunc2(x, y) result(r)
integer, intent(in) :: x
integer, intent(in) :: y
integer :: r
end function
end interface
procedure(Ifunc1), pointer :: pfunc1 => myfunc
contains
function myfunc(x, y) result(r)
integer, intent(in) :: x
integer, intent(in) :: y
integer :: r
r = x + y
end function
end module
|
Wait, what? Why are GNU Fortran users all "implementors", but users of other compilers not? |
Users of Same also applies with Consider the following: call sub( n )
contains
subroutine sub( x )
integer, intent(in) :: x
print *, "Hello World!"
end subroutine
end
Say a user is "annoyed" with the above warning, perhaps in the case of callbacks as indicated by But now in this case the user can employ a compiler option
The bottom-line to me is this does not appear a language standard matter. |
If this feature becomes available, I will definitely use it to suppress warnings about intentionally unused variables (because I always attach a check option to catch all unused variables).
To mimic this feature, I am using a CPP macro + associate to cheat compilers, like
and use it like |
When passing procedures as callbacks, sometimes a subset of the expected procedure parameters is not required and goes unused. Compiler tends to emit (false) warnings for unused parameters, despite this being deliberate in such cases.
In C++17, it is possible to suppress warnings on unused entities using the
[[maybe_unused]]
attribute:Another convention to prevent inadvertent use in C/C++ is to leave the dummy arguments unnamed:
In MATLAB, one can also ignore function inputs using the
~
symbol:Is there interest to have something similar in Fortran? An attributes syntax could be used for other purposes too.
The text was updated successfully, but these errors were encountered: