December 17, 2022 [Issue 18725] compiler does not check all levels of methods for privateness, if used in invariant | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18725 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P3 -- |
May 09, 2023 [Issue 18725] compiler does not check all levels of methods for privateness, if used in invariant | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=18725 RazvanN <razvan.nitu1305@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |razvan.nitu1305@gmail.com Resolution|--- |INVALID --- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> --- What happens here is that the invariant calls a private method which in turns calls a public method. Since the compiler inserts an invariant call before and after the call to `fun1` you get infinite recursion. >From the spec: "Do not indirectly call exported or public member functions within a class invariant, as this can result in infinite recursion" [1]. So I would say that this bug report is invalid. If the expectation is that the compiler checks for such indirect calls, then that is not going to happen since the frontend does not do dataflow analysis. The idea is that invariants check public functions. Private functions are exempt so that you can put your validation checks in a private function and call that one, however, what the code example is doing is calling a public method to check the invariant correctness. This bug is invalid. [1] https://dlang.org/spec/class.html#invariants -- |
Copyright © 1999-2021 by the D Language Foundation