On Tue, Mar 29, 2016 at 08:05:29PM -0400, Steven Schveighoffer via Digitalmars-d-learn wrote: [...] > Phobos treats narrow strings (wchar[], char[]) as ranges of dchar. It > was discovered that auto decoding strings isn't always the smartest > thing to do, especially for performance. > > So you get things like this: > https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/searching.d#L1622 > > That's right. Phobos insists that auto decoding must happen for narrow > strings. Except that's not the best thing to do so it inserts lots of > exceptions -- for narrow strings. > > Mind blown? [...]
Mind not blown. Mostly because I've seen many, many instances of similar code in Phobos. It's what I was alluding to when I said that special-casing strings has caused a ripple of exceptional cases to percolate throughout Phobos, increasing code complexity and making things very hard to maintain. I mean, honestly, just look at that code as linked above. Can anyone honestly claim that this is maintainable code? For something so trivial as linear search of strings, that's some heavy hackery just to make strings work, as contrasted with, say, the one-line call to simpleMindedFind(). Who would have thought linear string searching would require a typecast, a @trusted hack, and templates named "force" just to make things work? It's code like this -- and its pervasive ugliness throughout Phobos -- that slowly eroded my original pro-autodecoding stance. It's becoming clearer and clearer to me that it's just not pulling its own weight against the dramatic increase in Phobos code complexity, nevermind the detrimental performance consequences. T -- Obviously, some things aren't very obvious.