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".

In C++ another reason is exception safety. I am not sure if this holds for D as well since structs have different semantics for copy/move.

On 1/10/14 6:02 AM, Manu wrote:
> I won't start another annoying thread.

Great idea.

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

http://dlang.org/phobos/std_range.html#.dropOne

What do you want us to do, RTFM to you?

If you want to use Phobos, get your ass in gear and learn Phobos.


Andrei

On Friday, 10 January 2014 at 16:28:58 UTC, Andrei Alexandrescu wrote:
> On 1/10/14 6:02 AM, Manu wrote:
>> What's the go with popFront()... it returns nothing?
>> I almost always want to pop and return the front element.
>
> http://dlang.org/phobos/std_range.html#.dropOne
>
> What do you want us to do, RTFM to you?


I think he wants to return the popped element and this function does not do it. So it may actually be a missing convenience function.

On 1/10/14 6:02 AM, Manu wrote:
> What's the go with popFront()... it returns nothing?
> I almost always want to pop and return the front element.

After looking at the doc for 2 minutes, maybe this is what you want?
http://dlang.org/phobos/std_range.html#moveFront

On Friday, 10 January 2014 at 17:03:54 UTC, Kira Backes wrote:
> After looking at the doc for 2 minutes, maybe this is what you want?
> http://dlang.org/phobos/std_range.html#moveFront

Hm, forget this, this is moving the object itself not the iterator. So I think this is really missing.

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

popFront just pops the front element off the range.

int[] a = [1, 2, 3];
a.popFront();
assert(a == [2, 3]);

If you want to first element, just use front.

int[] a = [1, 2, 3];
int x = a.front;
a.popFront();
assert(a == [2, 3] && x == 1);

Warning, x has mutable references, it won't necessarily be valid after a call to popFront and an input range (e.g. byLine).

On 1/10/14 9:01 AM, Kira Backes wrote:
> On Friday, 10 January 2014 at 16:28:58 UTC, Andrei Alexandrescu wrote:
>> On 1/10/14 6:02 AM, Manu wrote:
>>> What's the go with popFront()... it returns nothing?
>>> I almost always want to pop and return the front element.
>>
>> http://dlang.org/phobos/std_range.html#.dropOne
>>
>> What do you want us to do, RTFM to you?
>
>
> I think he wants to return the popped element and this function does not
> do it. So it may actually be a missing convenience function.

Oh, I misunderstood. Anyhow, just wanted to convey some tough love to him :o).

Andrei

On 11 January 2014 00:31, John Colvin <john.loughran.colvin@gmail.com>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 <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;
> }
>

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.

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

One more, again here to reduce spam...

2 overloads exist:
void func(const(char)* str);
void func(const(char)[] str);

Called with literal string:
func("literal");

called with argument types (string) matches both.

I appreciate the convenience of the automatic string literal -> const(char)* cast. But in this case, surely it should just choose the array version of the function, like it does it calling with a 'string' variable? The convenience should be just that, a convenience, not a hard rule...?

On Sat, Jan 11, 2014 at 02:14:41AM +1000, Manu wrote:
[...]
> One more, again here to reduce spam...
> 
> 2 overloads exist:
> void func(const(char)* str);
> void func(const(char)[] str);
> 
> Called with literal string:
> func("literal");
> 
> called with argument types (string) matches both.
> 
> I appreciate the convenience of the automatic string literal -> const(char)* cast. But in this case, surely it should just choose the array version of the function, like it does it calling with a 'string' variable?  The convenience should be just that, a convenience, not a hard rule...?

File a bug against dmd for this? I agree that it should match the array overload, not the pointer overload. I'm not sure if it's fixable, though, due to the way overloads are resolved currently. But maybe Kenji has a way. ;)


T

-- 
"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous