On 10 January 2014 00:07, Manu <turkeyman@gmail.com> 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?

On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote:

> 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?

It seems you have to use both the .front property to access the element, and popFront() to advance to the next element.
I can't understand why you need two methods; maybe there's a very good reason for that.

On Friday, 10 January 2014 at 14:13:37 UTC, marcpmichel wrote:
> On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote:
>
>> 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?

There isn't (at least, not that I know of). I would be trivial to implement, but because it would be implemented in terms of front/popFront, it would not be any faster.

*However*, depending on the range type (non-transitive), popping might instantaneously invalidate the element you are operating on (think "byLine", that returns a "char[]", not a "string").

> It seems you have to use both the .front property to access the element, and popFront() to advance to the next element.
> I can't understand why you need two methods; maybe there's a very good reason for that.

You *need* two methods for the very simple use case of reading without popping.

As for returning the popped element when calling pop: It's an extra cost. C++ introduced back and pop_back (as well as pop/top) with those exact semantics for this reason. D also adds an issue of data integrity.

On Friday, 10 January 2014 at 14:02:21 UTC, Manu wrote:
> On 10 January 2014 00:07, Manu <turkeyman@gmail.com> 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*

On 2014-01-10 15:13, marcpmichel wrote:

> It seems you have to use both the .front property to access the element,
> and popFront() to advance to the next element.
> I can't understand why you need two methods; maybe there's a very good
> reason for that.

For optimization reasons. You don't always need both "popFront" and "front".

-- 
/Jacob Carlborg

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 <turkeyman@gmail.com> 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;
}

On Friday, 10 January 2014 at 14:31:31 UTC, John Colvin wrote:
> 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;
> }

*Unless* I'm mistaken, he was asking for something that returns the *popped* element?

Re-reading the question, it does kind of sound a bit ambiguous now.

On Friday, 10 January 2014 at 15:05:18 UTC, monarch_dodra wrote:
> On Friday, 10 January 2014 at 14:31:31 UTC, John Colvin wrote:
>> 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;
>> }
>
> *Unless* I'm mistaken, he was asking for something that returns the *popped* element?
>
> Re-reading the question, it does kind of sound a bit ambiguous now.

Woops, of course:

auto popFrontRet(R)(ref R range)
    if(isInputRange!R)
{
    auto tmp = range.front;
    range.popFront();
}


That also invalidates my second point to do with emptiness.

On Friday, 10 January 2014 at 15:19:39 UTC, John Colvin wrote:
> On Friday, 10 January 2014 at 15:05:18 UTC, monarch_dodra wrote:
>> On Friday, 10 January 2014 at 14:31:31 UTC, John Colvin wrote:
>>> 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;
>>> }
>>
>> *Unless* I'm mistaken, he was asking for something that returns the *popped* element?
>>
>> Re-reading the question, it does kind of sound a bit ambiguous now.
>
> Woops, of course:
>
> auto popFrontRet(R)(ref R range)
>     if(isInputRange!R)
> {
>     auto tmp = range.front;
>     range.popFront();
> }
>
>
> That also invalidates my second point to do with emptiness.

ugh, today is not my day:

> auto popFrontRet(R)(ref R range)
>     if(isInputRange!R)
> {
>     auto tmp = range.front;
>     range.popFront();
>     return tmp;
> }

On Friday, 10 January 2014 at 14:30:05 UTC, Jacob Carlborg wrote:
> On 2014-01-10 15:13, marcpmichel wrote:
>> I can't understand why you need two methods; maybe there's a very good
>> reason for that.
>
> For optimization reasons. You don't always need both "popFront" and "front".

mkay; this is a good reason indeed.
But maybe a simple pop() similar to the popFrontRet() above method could be added to the library. I know I looked for it the first time.