-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Should put and get do implicit conversions? #5045
Comments
I'd prefer if we had a more relaxed typing with the parameter framework. Then we also wouldnt have to do these horrendeous workarounds in swig that I added to avoid problems with this. |
I guess that means every arithmetic type can be casted to any other arithmetic type? |
what happens in c if you do |
It depends. With -Wconversion you get a warning and I guess if you combined that with -Werror you get a compiler error. Without that warning the floating point type is floored, ie a=3 |
I see....mmmh. Probably we would want to follow the behaviour that we have in our build, i.e. without those flags? |
Yes, I agree. I think that at least all integer types should be implicitly converted between them using the safe conversion helpers we already have. The same for floating points. Just from int to float I am not sure about... |
What I would do then is to have everything that doesnt loose information automatically. And then the ones which might loose information can simply print a runtime warning from shogun |
When we call
put
andget
we expect the cast types to match exactly:shogun/tests/unit/base/SGObject_unittest.cc
Lines 486 to 487 in 93a649b
However, does this make sense? In C++ it is valid for me to call a function with an implicit conversion:
Similarly, it is valid to implicitly cast a return type (so a getter can return int, but we store it as float64_t). So the test from above would fail, because the types would be casted implicitly, if we were using a getter (rather than
SGObject::get
):From a technical perspective this is possible to implement. My question is: would it bring more bugs than it would avoid? For example, on one hand a user might lose information by casting float to int, but on the other the program won't crash after 10 hours of training because of the type mismatch. I would also not want shogun to become like JS where everything has some result because the type system is too flexible.
The text was updated successfully, but these errors were encountered: