I created a PR #4322 for updating documentation for Str builtin. I like it when the docs have an expect
function as I find it clearer how it works and I like copying to the REPL, or my code to play with it. Can I ask someone to have a look and let me know if I'm on the right path so far? I don't want to get too far if the style I've used is wrong. Note I'm not removing any of the content that is already there.
One thing I had noticed was a comment around code snippets #2585. Should the expect
lines be left as is e.g. ## >>> expect Str.isEmpty "hi!" == Bool.false
or should I change them to be a code-snippet like ## expect Str.isEmpty "hi!" == Bool.false
?
I completed my edits for the Str builtin. I also made some minor edits in Num builtin. In the end I decided to stick with the ## expect ... format with 5 spaces as that enables type checking to work correctly. I tried to ensure all the types were formatted with [Str] and all functions were formatted \`my function\`.
This should be ready for review. My intention is to create another PR if I do another builtin.
All the functions have an expect
showing how it works with returns values. And where relevant I included examples of Err
.
Excellent UX improvement @Luke Boswell! I'm doing the final review right now.
I've been trying to figure our why CI is failing. Looks the CI is complaining about an issue in Dict.roc
with a missing implementation for listGetUnsafe : List a, Nat -> a
. It seems strange that it passed all the checks for PR #4318 which is where it was added, but is failing now. I haven't figured out what has changed since then. Maybe I shouldn't have merged main
into that branch?
Merging in main should not be a problem, I'll take a look.
All good now :)
Last updated: Jul 05 2025 at 12:14 UTC