Open CeylonMigrationBot opened 11 years ago
[@lucaswerkmeister] I’m a bit afraid that the error message for
Integer i = parseInt<Nothing>("10");
might be confusing, because the argument that’s not assignable to its type (null
) isn’t present here. Would the error be attached to the parseInt
node?
[@gavinking]
Would the error be attached to the
parseInt
node?
Um, that, or to the argument list, perhaps. Not sure.
[@lucaswerkmeister] Would this also apply to default type arguments? (Of course, that question doesn’t make much sense until #4067 is fixed.)
That would make my type system Turing machine a lot easier to use. At the moment, I have the following function:
// humongous return type omitted
t
<out State, out LeftStack, out LeftRest, out RightStack, out RightRest, Left, Right>
(B<State, LeftStack, RightStack> state, Left left, LeftRest leftRest, Right right, RightRest rightRest)
given State satisfies Q
given Left satisfies S
given Right satisfies S
given LeftRest satisfies Stack
given RightRest satisfies Stack
given LeftStack of StackEnd|StackHead<Left, LeftRest>
satisfies Stack
given RightStack of StackEnd|StackHead<Right, RightRest>
satisfies Stack
The arguments for left
, leftRest
, right
and rightRest
are always state.second.first
, state.second.rest
, state.third.first
, state.third.rest
, but in the t
declaration that’s not necessarily well-typed, so I can’t use these as default arguments and instead need to always specify them like this.
[@lucaswerkmeister] Maybe this should only happen for especially annotated parameters (e. g. with 'late')?
[@quintesse] I'd asked @gavinking if this was possible:
and it is except for the default value of
null
, which results innull not assignable to Integer|Absent
. Postponing that check to the invocation site would make this work.Low priority.
[Migrated from ceylon/ceylon-spec#594]