"TypeError: <func> is not a function" for functions with optional args

[Macket]

Contract: 0xFCBa3E75865d2d561BE8D220616520c171F12851
Method: def remove_liquidity_one_coin(_token_amount: uint256, i: int128, min_uamount: uint256, donate_dust: bool = False):

ABI for this method:

{
    "name":"remove_liquidity_one_coin",
    "outputs":[],
    "inputs":[
      {
        "type":"uint256",
        "name":"_token_amount"
      },
      {
        "type":"int128",
        "name":"i"
      },
      {
        "type":"uint256",
        "name":"min_uamount"
      }
    ],
    "constant":false,
    "payable":false,
    "type":"function"
},
{
    "name":"remove_liquidity_one_coin",
    "outputs":[],
    "inputs":[
      {
        "type":"uint256",
        "name":"_token_amount"
      },
      {
        "type":"int128",
        "name":"i"
      },
      {
        "type":"uint256",
        "name":"min_uamount"
      },
      {
        "type":"bool",
        "name":"donate_dust"
      }
    ],
    "constant":false,
    "payable":false,
    "type":"function"
}

I get an error "is not a function" when call this. Env: Node, Ganache

If I remove one of descriptions in ABI, it works.

[ricmoo]

If you have an ambiguous ABI, you must specify the fully qualified signature, since JavaScript cannot know which you meant to call.

So, you would need to use either:

// For the first:
contract["remove_liquidity_one_coin(uin256,int128,uint256)"](token_amount, i, min_uamount);

// For the second:
contract["remove_liquidity_one_coin(uin256,int128,uint256,bool)"](token_amount, i, min_uamount, donate_dust);

If you are only using 1 of the methods, I suggest removing the one you don't use. It's generally better to ship code that is as small as possible, so it is in your best interest to strip out any unused ABI methods. :)

For more examples, see: #407, #929, #1160

[Macket]

Thank you for the answer! Actually I have already removed the one I don't use, but I thought it's not the best practice :)

Why don't you choose signature according to number of args? Seems to be possible and convenient solution.

[zemse]

Why don't you choose signature according to number of args? Seems to be possible and convenient solution.

I think that's on the plan with v6, utilising the proxies 🤩

[ricmoo]

It isn’t possibly in many cases to detect which is the correct one based on the number of arguments. It is in some cases, but not in as many cases as you’d think and that would lead to very confusing behaviour as sometime it works and sometimes it doesn’t and you would need to have fairly deep understanding of how the optional (n+1)th overrides parameter works and would be superbly confusing for those using structures and could actually lead to outright ambiguous results.

In many cases the overrides are on types, in additional to quantities so it becomes the more complex still (should foo("0x1234") refer to the foo(bytes2) or the foo(uint256)?)

In v6 there is a Types object which can explicitly cast values to their types. If a person wished to use a declarative way to pass in parameters they will be able to use foo(Types.bytes2(v), Types.Overrides(overrides)) which allows a completely non-ambiguous lookup. Of course you could use import { bytes2, overrides } from "tbd" so the code looks more fluid.

As a quick aside, I have experience with this. I did have a branch at one point that used count to help isolate the intended call. There were many cases that it could not determine, which were not immediately obvious why, it most often didn’t help (as the types were what were overridden) and worst ended up in several bugs as it is easy to accidentally pass the wrong number of parameters in, and since there is so much overlap in types (e.g. an address is a valid uint256) and therefore call the completely wrong method. Debugging was unpleasant. :)

I’d rather just force people to either use a non-ambiguous ABI, explicitly specify which they want to use or in v6 fully declare the types. It leads to far fewer unhappinesses down the road. :)