Which Operator_Convert to implement for numeric type?

General
1

Hi,

for a numeric type, which Operator_Convert should I implement?
I tried to do all variants with various integer, float and currency types.
But compiler complains. I still want to avoid intermediate conversions due to loosing precision.
e.g. for Int64 I want no conversion to double. I want to handle Double and Int64 independent.

Any ideas?

2

this is a tad vague to know what you tried

be aware that in a 32 bit build a conversion of “integer” will be equivalent to int32
so you probably get a duplicate if you do conversion from integer & int32

and in 64 bit the same

should be able to skip doing Integer and everything should work

3

Is this related to 46010 ?

4

Yes. And 46014.
In both direction the compiler seems to behave correctly.

5

I did disable Integer in favor of Int32 and Int64, but it didn’t help.

6

46010 I dont find surprising that it does not behave as you think it should
Return types are NOT part of the signature and in that case there are 2 (or more) possible methods that could be called
That one requires no conversions to the result type and others do isn’t part of how the compiler figures out what method to call
If there are several candidates it just say “it’s ambiguous”
Thats not new - its been this way for ever

46014 I DO find puzzling as that should match precisely on the params given but isn’t
@Joe Ranieri will probably need to look at this and see whats up

7

Well, Operator_Convert is only useful, if I can have a way to provide all conversion with optimal conversion.
Int64, UInt64, Double and Currency should cover all number types as Int32 or Single can be upgraded without loosing precision.

Or I offer them all and compiler should never complain.

8

as input paramaters I am unsure why the example you gave doesn’t work as expected

as return types it makes perfect sense - return types are NOT pat of what the compiler considers
never have been from day 1

if you have

 
     function  f() as string
     function  f() as integer


     dim s as string = f()

this has NEVER compiled without saying “this is ambiguous”

So

   Class foo
      operator_convert() as double
      operator_convert() as int64
   end class


    dim f as new foo
    dim d as double = f

doesn’t surprise me this is ambiguous since it COULD convert foo to a double then assign it OR to an int64 then assign that (which results in an additional conversion to double) but EITHER would be legal

Which one is “best” isn’t part of the assessment

Never has been

9

well, I feared that you guys may not have special handling there for Operator_Convert.
But Operator_Convert is quite useless as it is today, at least for numeric conversions.

Operator_Convert should try to find an exact match for the type needed and the type provided. Than I can provide a dozen variants and enjoy a good conversion. In your example it should pick the double one as a a double is needed and the conversion via Int64 costs more. So it should prefer exact match and we would be happy.

10

And IF it had special handling to match the exact return type then why not make every function have that same special handling ?
That is what makes me pretty sure that operator_convert has no real special handling in this regard

Joe will need to chime in once he recovers from Thanksgiving

11

There are two bugs in the compiler’s overload resolution for conversion operators. Conversions to another type should rank exact matches highest and conversions from other types should follow normal overload resolution rules.

12

Can those be fixed soon?