Yes, I didn't think if using String.at/2 which would work and doesn't traverse the whole string.
If we think that checking a Strings length up to a certain limit is interesting, I'd still say that using `String.at/2` feels a little unintuitive. Also, it seems to be about 20% slower than my implementation of String.longer? for the same input (I did a benchmark with a 10 000 character string, with 5000 as limit). If there is any possible guarantees between byte size for graphemes in a valid utf-8 string, there is also room for the optimizations I mentioned in a longer? function, which is not possible to include in the at function. If we know that there is always at least as bytes as graphemes in a string, we could return false without traversing up to the limit in most strings when the string is shorter than the limit. The same goes for eagerly returning true for long strings if we know that no grapheme uses more than x bytes (even if x is 16 or some other fairly high value). I guess it breaks down to how verbose the stdlib should be, if there should be a minimal set of functions that works for most use cases or if there is room for specialized functions (and if this particular example is deemed useful enought to add the maintainability and compatability cost). 2016-06-25 20:13 GMT+02:00 John W Higgins <[email protected]>: > > On Sat, Jun 25, 2016 at 7:54 AM, Alvin Lindstam <[email protected]> > wrote: > >> Checking the length of a String requires traversing the whole string. I >> fairly common use case is checking if the String is longer or shorter than >> a given value. I might not be interested if the string is 123 456 graphemes >> long or 654 321, if all I want to know if it is longer than 50 000 >> characters, but still has to calculate the full length to know if it is. > > > What about String.at("bob", 4) != nil would test if "bob" was greater then > or equal to 4 chars in a single pass. > > John > > -- > You received this message because you are subscribed to a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/eY_YkhopJRA/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAPhAwGwM0aN_Mx2a-_mwe9qi_UNR91KMDH_BpkskSaXHS-D0%3DA%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAPhAwGwM0aN_Mx2a-_mwe9qi_UNR91KMDH_BpkskSaXHS-D0%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK2kfRKFJytF2ZFJUmoov013HeorpMN_vzqUN6Zs6njo7-H-WA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
