Closed StachuDotNet closed 1 year ago
Draft of TypeChecker.fs work:
| TTuple (firstType, secondType, otherTypes), DTuple (first, second, theRest) ->
// TODO: there's definitely a simpler way to gather these errors, but I'm blanking.
let errors =
[ (firstType, first); (secondType, second) ] @ List.zip otherTypes theRest
|> List.filterMap (fun (t, v) ->
match unify userTypes t v with
| Ok () -> None
| Error err -> Some err)
|> List.collect (fun errs -> errs)
match errors with
| [] -> Ok()
| errors -> Error errors
Some commentary here around autocomplete: https://github.com/darklang/dark/pull/4182#discussion_r912372275
Some commentary here around autocomplete: #4182 (comment)
Clicking this link doesn't get me anything (I think due to github folding). Might be worth copying the text or conversation if it's valuable.
Odd. It takes a second to jump to the right place for me, but does.
Copied commentary:
I think this needs code to parse this (and tests!). I think adding tuples to the interestingDvals should find this.
I also get an error in Blazor when calling functions with tuples of 3 or more iterms:
I think we shouldn't support tuple-typed function parameters until we support polymorphic type signatures. With (I think) all the existing types, such as
TList
, there's an easy conversion from the old value to the new one:Tlist
becomesTList TAny
. However, in TTuple, we encode the number of type arguments as well as their actual argument. So if someone has aTTuple
, and they call it with a tuple with 7 members, how will we know to convert it toTTuple(TAny,TAny,TAny,TAny,TAny,TAny,TAny)
instead ofTTuple(TAny,TAny)
.
Works in daarklang-next (client part not applicable)
As of #4182 we won't be allowing users to use tuples quite yet, so this functionality seems safe for now.
There are a few parts: