On 1/29/26 4:28 PM, kdevel wrote:
> On Thursday, 29 January 2026 at 20:44:17 UTC, Ali Çehreli wrote:
>> On 1/28/26 12:37 AM, kdevel wrote:
>>> On Tuesday, 27 January 2026 at 02:05:45 UTC, Ali Çehreli wrote:
> [...]
>>>> auto example_func(bool fail)
>>>> {
>>>>     alias filterFunc = a => a != "expensive";
>>>>     alias mapFunc = a => tuple!("value", "numLetters")(a, a.length);
>>>>
>>>>     auto makeRange(R)(R r = typeof(someExpensiveOperation()).init) {
>>>>         return r
>>>>             .filter!filterFunc
>>>>             .map!mapFunc;
>>>>     }
>>>>
>>>>     if (fail)
>>>>     {
>>>>         return makeRange();
>>>>     }
>>>>
>>>>     auto list = someExpensiveOperation();
>>>>
>>>>     return makeRange(list);
>>>> }
>
> Your function is equivalent to

No because you don't apply filterFunc or mapFunc below.

>     auto example_func (bool fail)
>     {
>        alias filterFunc = a => a != "expensive";
>        alias mapFunc = a => tuple!("value", "numLetters")(a, a.length);
>
>        auto list = fail
>           ? typeof(someExpensiveOperation()).init
>           : someExpensiveOperation();
>
>        return list
>           .filter!filterFunc
>           .map!mapFunc;
>     }
>
> but it has only two levels of indentation and no nested function
> (template). Alas it shares the duplication of "someExpensiveOperation()".

The problem is, one has to repeat filterFunc and mapFunc as well. And that's why a nested function solves the repetition issue elegantly for me.

>> I must have misunderstood but it fails fast because it does nothing at
>> all before returning the empty result. (The OP's goal.)
>
> Maybe the OP favors a different definition of "fail fast" as the
> function under close scrutiny is not failing at all.
>
>        FailFast also refers to some programming techniques that cause
>        an exception to be thrown or other redirection of control to
>        occur upon meeting certain conditions. [...]
>
>        http://c2.com/

I must have read too much into the subject line: "empty" result. That's why I'm reminded of this simple technique that I used in the past. I assumed the OP was like me: the caller should not be bothered by exceptions, rather an empty result should be returned.

Ali

Reply via email to