Type instantiation is excessively deep and possibly infinite
Produces error:
28 Replies
Do you know if this is a regression/when it worked?
This should be an easy one to fix at least. If it is only infinite when one side of the type is extracted, it's a bug in
distillI'm pretty sure it worked in the past but I don't know when
Yeah I made some changes recently to distill I'll fix this right away though
Hmm there's really a whole set of narrowed inference that will fail if you infer out of a morph first which forces
constrain<X, Y> to evaluate
This is why I originally wanted constrain to not be a subtype of the original type but at some point it seemed like I could extract what I needed so I went with it. Once you have an intersection like string & {[constrained]: constraints} it is not possible to get back to string without enumerating all the possible builtins I want to check for which kinda sucksWhat would an alternative way be?
Just have the constrained types be a tuple or something like
[base, "constrain", constrained]
But then they couldn't be used directly
Not that they ever really are at the moment
Morph types already work that way- they can't be used directly to represent the actual dataSo right now it's more of future-proofing?
Well for now the branded types are always assignable to the base type
I will keep it that way, I found some nonsense I can do to work around it
Since obviously that is ideal
But there's not really a builtin API for actually using the branded output types by default yet
Maybe would be a global config at some point so you can choose if you want branded types
But having the information encoded in the type opens up a lot of other possibilities also. The original reason I added it was to support pattern matching
What do you mean by nonsense and how come it's ideal if it's nonsense?
Because the external inference is ideal, but internally it requires a lot of hoop-jumping
I see!
You're jumping all the hoops so that we have ideal inference 🤗
Well that is essentially the entire premise of arktype 😛
And man is the inference ideal
Well I'm fixing some cases where it was not now haha
Also I really like the new
type.infer syntax
What is the reasoning behind it being capitalized in type.infer.In and type.infer.Out?I wish I didn't have to but
in is a reserved keywordUnderstood
And so Out is also capitalized for consistency
Yeah
In other contexts e.g. as a property it's actually fine
But you can't define it as a type like that
So I just end up capitalizing it there rather than come up with a different name everywhere else when it's mostly ideal
At the same time it plays well in the situation of
tIn
RightttttIn is actually gone now I renamed it to match those other methods
inferBrandableIn
Better that it's more descriptiveNot
infer.brandable.In?So that is the namespace type, but in terms of the prop attached to
Type, it's better that you can access it shallowly because at a type-level t["infer"]["brandable"]["In"] is pretty painful to write 😛Got it!
Yeah, that looks like my types haha
I never created namespaces before
Yeah they're really mostly just useful for organizing types to make them easily discoverable- mostly useful for library APIs
Is there string.bigint.parse yet?
No you should add it
Got it, thank you 👍
What would be cool is if we could do
type("bigint>0n")Yeah compartors are one of the oldest parts of ArkType. When I was first building them, bigints weren't actually used very often so I didn't prioritize adding that syntax
Would definitely accept an issue/PR though. It would be relatively achievable for an external contributor because it would just mirror the design of the other bound kinds