very silly question, is there an easier way to validate the length of a trimmed string?
errors with
Uncaught ParseError: MinLength operand must be a string or an array (was never)
appears to work, but this seems unergonomic when most other string keywords allow length specifiers. I know that this is a morph rather than a simple narrowing, but it is surprising!8 Replies
There is a better way to do this that I need to document! When you pipe to another type, you can use
.to("string > 3")
and it accepts a definition directly
But also I'm not sure that's the best result we could give there. Usually applying a constraint like that would apply it to the input (that's how intersections work).
In the vast majority of cases like that, if it seems feasible we could give a type error and didn't (it is here), but then throw a ParseError
, something may have gone awry
@francis In the past, since intersections apply to input and constraints are intersections internally, string.trim > 2
was allowed and applied it to the input.
At some point though, I realized that constraining a morph directly is unintuitive/ambiguous and changed it to catch that case and fail.
Just realizing now that I didn't update the string validation to reflect that (it still extracts the input) so going to do that as part of the next release!
Will also update the runtime error to be clearer. Just updated it to MinLength operand must be a string or an array (was (In: string) => Out<string>)
, but may add a hint about constraining input or output directlyah yep this makes perfect sense. I agree with not allowing this - since it's not obvious whether the length requirement should apply before or after the trim, you could make an argument either way
If it did apply it would definitely be before for a lot of reasons, but yeah best not allow it
ah, and I want it to apply after in my case 🙂 which I thought of as the "natural reading"
(mainly that you don't really think about it externally, but internally we generally have no way to introspect at all what the output of your transform is so we can't do anything w ith it)
going left to right I was reading it as "trim the string, then validate the length"
No I mean after is better here and would normally be what you want
But fundamentally from a type system perspective, you can really only introspect and interact with input types unless output types are explicitly declared
Which to be fair they are on
string.trim
since it's internal and we can do that, but if we wanted to generally allow constraints on morphs, it is not possible to do with outputWill be like this next release
