-
Notifications
You must be signed in to change notification settings - Fork 18
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
Support for type casting #59
Comments
hmm... I could build an
Then you'd get
and have the |
The idea of using But then it could be nice to be able to use both
I can understand. But at the same time, it is widely spread in PLs, tough often misused ;-) One thing, which is sort of nice is that it allows you to pass in types that didn't exist at the time of writing the original code. But the biggest problem with automatic conversions is that it is so hard to track them and see when they are applied by a compiler/runtime (and I guess it is the main reason you don't like them). If there would be tools/means which would make it easy to see conversions performed at run-time, then they'd become (much more) harmless, IMHO. Most of their black magic would disappear in this case. |
Here is the idea:
Shine should allow to define custom cast operators/functions.
If there is a check somewhere like "o is T1" (e.g. for a function parameter) and it fails at runtime, because the actual value has a different type T, Shine currently issues an error. With this proposal, Shine could try as a fallback to find a cast from T to T1. If it exists, it would apply it and thus satisfy the condition "o is T1".
The search for a cast operator may happen e.g. in the meta-methods of T or T1.
The text was updated successfully, but these errors were encountered: