On 11 January 2014 00:31, John Colvin <[email protected]>wrote:
> On Friday, 10 January 2014 at 14:28:09 UTC, John Colvin wrote: > >> On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote: >> >>> On 10 January 2014 00:07, Manu <[email protected]> wrote: >>> >>> This works fine: >>>> string x = find("Hello", 'H'); >>>> >>>> This doesn't: >>>> string y = find(retro("Hello"), 'H'); >>>> > Error: cannot implicitly convert expression (find(retro("Hello"), >>>> 'H')) of type Result!() to string >>>> >>>> Is that wrong? That seems to be how the docs suggest it should be used. >>>> >>>> On a side note, am I the only one that finds std.algorithm/std.range/etc >>>> for string processing really obtuse? >>>> I can rarely understand the error messages, so say it's better than STL >>>> is >>>> optimistic. >>>> Using std.algorithm and std.range to do string manipulation feels really >>>> lame to me. >>>> I hate looking through the docs of 3-4 modules to understand the >>>> complete >>>> set of useful string operations (std.string, std.uni, std.algorithm, >>>> std.range... at least). >>>> I also find the names of the generic algorithms are often unrelated to >>>> the >>>> name of the string operation. >>>> My feeling is, everyone is always on about how cool D is at string, but >>>> other than 'char[]', and the builtin slice operator, I feel really >>>> unproductive whenever I do any heavy string manipulation in D. >>>> I also hate that I need to import at least 4-5 modules to do anything >>>> useful with strings... I feel my program bloating and cringe with every >>>> gigantic import that sources exactly one symbol. >>>> >>>> >>> I won't start another annoying thread. >>> >>> What's the go with popFront()... it returns nothing? >>> I almost always want to pop and return the front element. I can't find a >>> function to do that... have I missed something again? >>> >> >> Popping the front off a range doesn't necessarily require the work needed >> to return the front itself. A trivial example would be a range of e^n : >> popFront just incrememnts n but calculating front requires the relatively >> expensive exponentiation. >> >> Also, it is legal call popFront on a range with only one element >> remaining, leaving it empty. It is not valid to then look at the front. >> >> You want both at once? take a look at the various std.range.take* >> > > or if you want something short and simple, define a free function: > auto popFrontRet(R)(ref R range) > if(isInputRange!R) > { > range.popFront(); > assert(!range.empty); > return range.front; > } > This is what I've done. I'm just surprised that such an obvious function doesn't exist, and suspect I was just retarded at phobos again. Having a function that does this is kinda important to simplify lots of expressions that otherwise need to be broken out across a bunch of lines. Does nobody see this coming up in their code? I have it basically every time I use ranges, and as usual, surprised others don't feel the same way.
