CFCs in ACF support argument type of integer but Lucee does not.
Description
Activity

Bradley Hicks 1 February 2018 at 15:44
I was not surprised to see 8.0 be rejected. I also, for reasons you describe, wouldn't have been surprised if it succeeded. 8 == 8.0, or 8.0000.
I have no preference, but I think ACF might do this for type consistency between application layers (but ACF is not famous for such considerations). Granted, a good developer will maintain type consistency on their own, especially since Cold Fusion is a little loose with it.
I do think it should complain as an assist to developers who might try to use integer for fractional monetary values, whether deliberately or accidentally.

Michael Offner 1 February 2018 at 14:49
actually i'm not even sure, if it should complain if you pass 8.1 and you are loosing data, take this example
converting the number to a string you only get 8, so you are loosing data, converting a number to a string always comes rounding the number to a certain extend, otherwise converting for example the following would be never possible:

Michael Offner 1 February 2018 at 14:37(edited)
this is a feature that was added to ACF12 as it seems, does not work with ACF11.
Why it should be expected that the following code fails is not clear to me:
Example 1
specially because this one works fine
Example 2
When you pass a value to a function (or return one), the type definition with arguments (or return type) does not actually convert that value to type defined, it only check if it can convert to that type.
Take this example:
Example 3
in that example you will see that the CFML Engine will not convert the string passed in to a number (java.util.Double), no it only checks if it can.
so if you pass 8.0 it is not able to convert it to 8, but it can convert all other simple types?!
string to boolean|number|date
boolean to string|number|date
number to string|boolean|date
i understand that converting a double to an integer can come with a lost of data and in that case you should complain of course, but not in case it is perfectly fine without loosing any data and testing this is not very complicated and does not take that much time.
In my opinion the ACF implementation looks half baked and we should for sure not adapt it as it is.
It is inconsistent with the current behaviour of converting simple types and it is inconsistent in itself (see Example 2).
In addition if we change the behaviour we cannot do it before version 5.3. Changing this could break existing code.

Pothys - MitrahSoft 1 February 2018 at 14:10
I've added test case for this ticket & ACF-2016 only support whole numbers like TestNum(8) and do not support point numbers like TestNum(8.3). Lucee, ACF-10 and ACF-11 throws an error while argument type is an integer.
Pull Request: https://github.com/lucee/Lucee/pull/386
Details
Details
Assignee

Reporter

New Issue warning screen
Before you create a new Issue, please post to the mailing list first https://dev.lucee.org
Once the issue has been verified, one of the Lucee team will ask you to file an issue
This code as desired in ACF, but Lucee doesn't support the integer type for arguments.