>I realize this, but let me make my point:
>1. This is the module trait we are talking about. Even with package, depending on *anything* in algorithm *will* pull in `range`, `array` and `uni`. It's ludicrous.

A drag, yes, but not ludicrous.

>2. "slippery slope": Yes. I wouldn't do this for any other module.

Any current module, or any future module? The way I see it if we do it here we may as well export the practice elsewhere in the future. There's nothing about this module that makes it fundamentally different and deserving of a special regime. We need to attack the problem differently.

>3. The functions duplicated are *more* than rivial. `startsWith` for strings? 1 liner. As for `_text`, it is *really* just reduced down to *nothing* but string concatenation. I could remove it entirelly and use "~" instead, but at a cost to readability. I use `_UIntToString` in *1* place. *That* could be placed in a teeny tiny package, I agree, but it's hardly complicated.

Yah, converting integers to strings is also trivial so why not provide an inefficient, incomplete, and buggy implementation of it elsewhere too? It's a six liner. More importantly, where do we stop?

>May I kindly ask you re-evaluate and reconsider? I'll revert back if you say I should, but I think it would be a real shame. Importing algorithm just to find out if my string has the word "module"? It just seems way excessive to me :/

>Please advise.

This has little to do with strings containing substrings. I'd say if we need to rely on idioms based on code duplication we have a problem elsewhere. *That* we need to fix.