Error when deserializing (f64, f64) type

[Maximkaaa]

I'm using Rust api for IC, and have a query method with the return type (f64, f64). This type is serialized correctly by candid, and the type info is saved correctly, but when using Decode macro on this type, I get an error:

Custom(Fail to decode argument 0 from float64 to record { float64; float64 }

Caused by:
    0: input: 4449444c00027272_000000000000f03f000000000000f03f
       wire_type: float64, expect_type: record { float64; float64 }

Debugging deeper into the Decode macro, I can see that the message header is read having

candid::binary_parser::Header
  args -> [
    { index: -14 },
    { index: -14 },
  ]

e.g. two floats. But processing further this gets boiled down to single float for some reason.

The reason I am sure this must work is because the methods with return type (u64, u64) work without any issue.

[nomeata]

This looks like a confusion between an argument or result sequence of two floats, and a tuple of two floats.

Can you show which macros you use to endode/decode?

[Maximkaaa]

@nomeata This is how I decode the value:

Decode!(result.as_slice(), (f64, f64)).unwrap()

Encoding is done by ic_cdk as I just return the value from the query method:

#[query]
fn my_method() -> (f64, f64) {}

[nomeata]

Try

Decode!(result.as_slice(), f64, f64).unwrap()

[Maximkaaa]

Yes, it does work this way. Thank you.

Can you explain, why in my code if I use u64 instead of f64 it works? I mean

#[query]
fn my_method() -> (u64, u64) {}
Decode!(result.as_slice(), (u64, u64)).unwrap()

This produces the correct result. What's the difference with f64?

[nomeata]

That is odd, should behave the same. Are you absolutely sure, and didn't maybe forget to recompile or so? (Anyways, I'll leave this this to the rust library developers.)

[Maximkaaa]

Yes, I'm positive about it. I have at the same time methods returning f64 and u64 tuples.