Closed shriram closed 4 months ago
Instead of having the new function raise an error, can we return an option type? There are situations (concretely, in a cs111 homework) in which it's useful to search for the first substring that matches a pattern if it exists, and if it doesn't, do something else in the function body, rather than erroring out.
I guess we need both? substring-at-opt
and substring-at-exn
?
I don't like those names; to me, substring-at
should take a string and a number and return the substring at that index (which then begs the question of the length of the desired substring...) I'd pick string-find-index
instead. I'm not sure to distinguish the two variants, though: The only parallel design we have is dict.get
(Option) vs dict.get-value
(error-throwing), and name-to-color
(Option) vs color-named
(error-throwing). So maybe we have string-find-index
(option) and string-get-index
(error-throwing)?, with the idea that "finding" might not find, but "get" demands a result "or else"?
I like this naming convention. Does it sense to apply it more widely?
"This" is ambiguous -- do you mean your proposed naming convention (-at-opt and -at-exn) or mine (-find-index and -get-index)?
Yours!
Currently,
string-index-of
returns-1
in the error case, which violates DCIC and good programming practices.@blerner thinks it might be because it was useful for Bootstrap, but @schanzer confirms that Bootstrap never uses it.
@jpolitz is concerned about breaking backward compatibility.
Can we:
string-index-of
to say it's been deprecated and is only there for legacy reasons.Suggested name:
substring-at
.