I have done now a search in my largest VO project for all occurrences of _cast and found only 1.649 of them <g>.
Most of them are in the VO Class libraries code and in the bBrowser, and the others in code to enhances ListViews or interface to MAPI, and some of them adress the return value of PCALL().

Personally, I would mark all casts with usuals as errors, so we should look at them and correct the code.
IMHO it is better to fix code than to have some code that don't works and we don't know why.
Casts to typed values, and specially to value types are relatively safe. Casts to typed reference values are to check because in .NET they could give undesired (or wrong) results.

I like the idea of throwing an error on using _CAST with USUALs. But maybe not with integer numeric types (and LOGIC probably), because there's probably a lot of existing code that uses that and it is safe to use it in VO, so in order to make it easier to directly port code, I think it's better to allow it.

In any case, all <integer type>(_CAST, uUsual) conversions (because they are not really casts in .Net) do already work in X# in a VO compatible way, except for SHORTINT. I think it's better to make SHORTINT work, too, and report a warning about those conversions that they will not work in other platforms (although it is not very likely to run a VO ported app in a different platform )

I would vote for a warning if the compiler detects _cast problems, similar like he already does in this case:

PTR( _CAST , cText )

warning XS9068: The compiler generated an automatic conversion to PSZ. This may create a memory leak in your application. Please use String2Psz() to let the compiler manage the lifetime of the PSZ or use StringAlloc() and manage the lifetime of the PSZ yourself.

Inspired by this thread I´ve looked at the integer() function. I've noticed that Integer() returns negative numbers as soon the integer is greater than int32.maxvalue. But this happens also if such integers are assigned to usuals or floats.

Sorry for the delay and thanks for the report, problem confirmed and logged!

Does not seem related to the Integer() function, though, but it's a compiler problem treating the expression "2147483647 + 1" as an int (which overflows), instead of using a larger numeric type before assigning it to the USUAL or FLOAT var, Robert will look into it.