rename `any` to `RESTany` about framework HOT 3 OPEN

I see, then we will need to introduce a python script at the validation pipeline, similar to validateProcesses.py, or inside validateProcesses.py that certifies that no any statement appear at the process header.

from framework.

Another option would be to avoid using using namespace std; at the headers? And then write directly std::any when willing to use the c++17 standard one.

There are not many classes to modify in that case:

galan-gifna:source javi$ grep -rnw . -e "using namespace std" | grep .h:
./framework/tools/inc/TRestReflector.h:28:using namespace std;
./framework/tools/inc/TRestSystemOfUnits.h:20:using namespace std;
./framework/tools/inc/TRestDataBase.h:10:using namespace std;
./framework/tools/inc/TRestStringHelper.h:24:using namespace std;
./framework/tools/inc/TRestTools.h:31:using namespace std;
./framework/tools/inc/TRestPhysics.h:27:using namespace std;
./framework/tools/inc/TRestStringOutput.h:24:using namespace std;
./framework/core/inc/TRestTask.h:22:using namespace std;
./libraries/detector/inc/TRestDetectorGeometry.h:35:using namespace std;
./libraries/detector/inc/TRestDetector.h:35:using namespace std;
./libraries/geant4/inc/TRestGeant4ParticleCollectionDecay0.h:15:using namespace std;
./packages/restG4/include/SteppingAction.hh:15:using namespace std;
./packages/restG4/include/EventAction.hh:37:using namespace std;
./packages/restG4/include/RunAction.hh:44:using namespace std;
./packages/restG4/include/PrimaryGeneratorAction.hh:48:using namespace std;
./packages/restG4/include/PhysicsList.hh:44:using namespace std;

Perhaps then we can just have a validateCode.py that checks if using namespace std; is found at the headers files.

from framework.

👍 for the change, because up to now I thought the usage of any was indeed referring to C++'s std any.

Aside from that I would personally rather use something inherently safer than something like what we have here now, e.g. std::variant (obv. not available since we do not target C++17 I suppose):
https://en.cppreference.com/w/cpp/utility/variant

The problem I see with the current approach is that it's inherently unsafe, unless one uses the GetValue helper. But in practice that doesn't seem to be used, e.g. here:
https://github.com/rest-for-physics/framework/blob/master/source/framework/core/inc/TRestAnalysisTree.h#L118

If the user calls GetObservableValue<int>(…) but the stored value is actually a float this produces garbage and there's no runtime checks for this. Personally I would remove the ability for direct access to the pointer in TRestReflector and force the usage of GetValue. There can be a more verbose and possiblye "dangerous" way, i.e. an unsafe_ptr proc for the case where one really wants to avoid the if check. But imo that shouldn't be necessary, because code that is performance critical should never use such objects anyway.

Naming wise I would choose something like RestValue.

from framework.