Sean T Allen

So... to do this, we need to touch a number of other data structures... this appears to be the diff to thread everything through: ```diff diff --git a/src/libponyc/ast/ast.c b/src/libponyc/ast/ast.c index...

The problem isn't with inference on numbers. using any non-negative number for the default works fine. It's the negative that is tripping this up.

Specifically, this is in the handling of `call`: positive integer: ``` (params (param (id f) (nominal (id $0) (id I8) x val x x) (seq:scope 1))) ``` negative integer: ```...

in `partial_application` in `call.c` in the expression pass we have: ``` // `$0.f` BUILD_NO_DECL(call_receiver, ast, NODE(TK_DOT, NODE(TK_REFERENCE, ID(recv_name)) TREE(method))); ``` the `ast_type(call_receiver)` result goes boom eventually as the type comes...

So really this looks like that all the code from partial application on out doesn't expect a call to have a literal as a receiver but we do here and...

backtrace w/ release ponyc. ``` frame #2: 0x00000000007963d2 ponyc`ponyint_assert_fail + 258 frame #3: 0x000000000073ac3d ponyc`lookup_base + 1293 frame #4: 0x000000000073a729 ponyc`lookup + 25 frame #5: 0x0000000000743ff4 ponyc`verify_function_call + 532 frame...

Anyone interested in working on this can contact @SeanTAllen to get additional information re problems that need to be addressed to make this happen. It's a bit more involved then...

During sync, @jasoncarr0 brought up the point that maybe there's no point to allowing an iso here as you can't do any "iso things" with it. There's nothing "valuable you...

@csos95 would you like to handle the PR to fix this?

I think we can assume that this is available for anyone to work on at this point and that @csos95 has moved on to other things.