[Issue 14485] .front of empty filtered zip range is accessible

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=14485

--- Comment #4 from Vladimir Panteleev <thecybershadow at gmail.com> ---
(In reply to Jonathan M Davis from comment #3)
> And since it's normally considered a logic bug in a program if it doesn't
> check empty before calling front or popFront on a range, I'm not sure how
> much sense it makes to have a function which takes a range, checks empty,
> and then throws if it's true and returns front if it's not.

Use your imagination :)

Here's my code:

string findProduct(string name)
{
    return
        ("http://www.tp-link.com/en/search/?q=" ~ encodeComponent(name))
        .download
        .readText
        .toXML
        .xmlParse
        .I!(doc => zip(
            doc
            .findAll("#productResult > li > dl > dt > a")
            .map!(e => e.attributes["href"])
        ,    
            doc
            .findAll("#productResult > li > dl > dt > a")
            .map!(e => e.children[$-1].text.strip)
        ))
        .filter!(t => t[1] == name)
        .front[0]
        .I!(s => "http://www.tp-link.com" ~ s)
    ;
}

As you can see, stopping to check .empty in the middle of this UFCS chain would
be quite inconvenient. Thus, there should definitely be a "safeFront" function
OSLT.

--