For easy discoverability, we could make a Str.len function that returns LearnAboutStringsInRoc "<copy of text in https://www.roc-lang.org/faq.html#strings-in-roc>"
I've thought about this, but I think it's probably best to find another way. The tradeoffs are:
Str functionYou could just have a special case for when you have a non-existent symbol. Is the qualifier Str that resolves to builtins.Str, and the symbol len? Return the above error instead of the usual one
@Anthony Bullard are you talking about automplete specifically? What does "the usual one" refer to?
helps beginners very briefly
It could be a make or break moment though, people will give up on Roc if they find it too difficult to code the behavior they have in mind.
cluttering their docs
It could be an asset in the docs as well, when they're searching for len because they expect it to exist.
autocomplete results
There are currently no other Str functions that start with an l so I don't expect this to be a problem in practice.
LLMs may get confused and try to use it based on the name
This should also be fine in practice (in the near future), Roc training data will not contain .len for Strings because it's not useful in real code.
We could also evaluate having this function and get rid of it if it does not turn out well. That won't break any production code :p
true!
I'm up for trying it
This seems like something that would be better handled with editor tooling in the future, e.g. if you write Str.len you get a red squiggle underline with a message. Actually, this could already be done if roc check showed a warning for Str.len
That would still leave the scenario where people type len in the docs website search bar, see nothing and then think; "what now?". People may also type l or le on a Str for autocomplete, see nothing and need to reach for the browser to find answers.
Last updated: Jun 16 2026 at 16:19 UTC