Add new algorithm: either()

[nordlow]

Thanks to D's lazy parameters this new variadic function either simplify pattern matching.

either() is similar to Python/Lisp's or. Same as Phobos's any but returns first parameter value which implicitly convert to true, or last argument otherwise. I guess any could be modified but that would cause breakage on its return type.

I've found real use of either()in various parsing contexts.

I'm very open to changing the namings if you feel they are misguiding.

Note that either currently cannot be nothrow because of issue https://issues.dlang.org/show_bug.cgi?id=12647

[DmitryOlshansky]

2 things to note:

• lazy had awful codegen last time I've seen it
• tryEvery is quite non-obvious in how it expects each lazy parameter to affect the same haystack it then restores on failure. A simpler approach is to just make each parameter a callable that accepts ref S whole.

[DmitryOlshansky]

These array appends would be highly problematic for the performance of a parser...

[nordlow]

Done. I return fixed length bool array instead.

[DmitryOlshansky]

@nordlow Please do not merge with master, do:

 # if upstream is dlang/phobos  remote
git pull --rebase upstream master

[nordlow]

I just realized that it's better for tryEvery to return either a

• a bool true upon matching of all arguments, false otherwise,
• a size_t counter that somehow indicates how many arguments that could be matched or
• a Voldemort struct with count member and implicit bool conversion rules that enables the nice idiom

if (const hit = haystack.tryEvery(needles...) 
{
    // do something with `hits.count`
}

I prefer the last alternative as it will harmonize with the interface of the pending

#3288

What do you guys think?

[andralex]

Nice, two things:

1. Could you please try whether it's possible to accept/return by reference? I.e. either(a[0], a[1]) = 1; should work. But I don't think auto ref cooperates nicely with lazy.
2. A predicate would help, e.g. choose either non-empty string: auto s = either!(s => !s.empty)(param, "default");. In fact I think such use would be most useful.

[MetaLang]

You need to ensure here that CommonType!Ts is not void.

[MetaLang]

I'd like to propose a different implementation for either. I think an iterative approach is preferable for efficiency reasons.

CommonType!Ts either(Ts...)(lazy Ts a) 
if (a.length >= 1 && !is(CommonType!Ts == void))
{
    foreach (ai; a)
        if (ai) 
            return ai;

    return a[$ - 1];
}

[CyberShadow]

So either/every are any/all except they return non-bool? Does the distinction make them useful enough to add considering the overlap in function? Can we change any/all instead?

Yes, either/every operate on a tuple, and any/all on a range. But seeing as the functions require that they have a common type, you can use any/all with only, right?

tryEvery seems too specialized for Phobos.

[DmitryOlshansky]

tryEvery seems too specialized for Phobos.

+1 I'd also point out non-obvious conventions in its usage.

[nordlow]

Made either and every iterative instead.

[MetaLang]

This will return a[$ - 1] even if it's falsy.

[nordlow]

So which lvalue should be returned if all parameters bool-convert to false? We can't use CommonType!Ts.init because that's an rvalue. Any ideas on this, @andralex?

[MetaLang]

It seems that the only sensible thing to do would be to throw an exception or assert, but that seems too heavy for such a small function. Maybe have the user provide a default value? It doesn't really make sense, but I don't see much of an alternative. What do Python and Lisp do when all values evaluate to false?

[nordlow]

Python:

assert((0 or False) is False)
assert((False or 0) is 0)

assert((False and 0) is False)
assert((0 and False) is 0)

assert((0 or None) is None)
assert((None or 0) is 0)

Emacs Lisp:

(and 0 nil) => nil
(and nil 0) => nil

(or 0 nil) => 0
(or nil 0) => 0

[MetaLang]

Ah, okay.

[nordlow]

IMO the important thing here is to have the same behaviour for l-values as for r-values. If so I see three alternatives here:

1. Mimic Python's behaviour (in order to get same behaviour for l-value and r-value returns);
   • either returns last argument upon no true-conversion
   • every returns first argument upon no true-conversion
2. If default value is supplied return it upon failure for r-value overloads of both either and every. For the l-value overload we could force the default value to be an l-value via ref parameter in this case, right?
3. Throw Exception (if no default value is supplied).

What do you think?

[nordlow]

Ping. I'm sensing we need a voting on this matter.

@andralex ?

My standing point here is a behaviour that is easy to remember.

[andralex]

should be fine as is

[nordlow]

The latest commit contains a todo; there's a problem with the conversion trait. It doesn't work with arrays. Is there an alternative trait?

[JakobOvrum]

It's not just nothrow, it's all function attributes.

edit:

Or not. Huh.

[nordlow]

So should I remove this comment for now or tell that no attributes can be inferred?

[andralex]

Couple more nits and we're ready to go... again :o).

[nordlow]

After my latest changes in the first either-overload we need to restrict it to not allow it when all variables are l-values. This in order for the second overload to kick in. How do I do that? Because of this the unittest for either now deliberatly fails as

comparison.d(2017,11): Error: either(x, delegate int() => y) is not an lvalue

[andralex]

Regarding lvalues: I'd say let's just forgo them.

[nordlow]

• Ok @andralex , removed l-value ref overload
• Updated to use pred(T.init) instead of pred(T())
• Removed array-check from ifTestable().
• Moved ifTestable to std.traits
• Added docs to ifTestable
• Added static unittests for ifTestable to prove that pred is indeed evaluated

IMO, we're ready.

[andralex]

Just replace these two lines with allSatisfy!(ifTestable, T, Ts)

[andralex]

One last nit. Then I preapprove (it sounds... oxymoronic).

[nordlow]

Done!

[andralex]

Auto-merge toggled on

[andralex]

thx!

[nordlow]

Great!

[nordlow]

Just realized that we can make use of typeof(return) in

CommonType!(T, Ts) either(alias pred = a => a, T, Ts...)(T first, lazy Ts alternatives)
    if (alternatives.length >= 1 &&
        !is(typeof(return) == void) &&
        allSatisfy!(ifTestable, T, Ts))

Would that be preferrable in other PRs to reduce redundancy and perhaps number of instantiation tries?

[JakobOvrum]

This still isn't passing the predicate to ifTestable, despite my comments...

[nordlow]

Should we revert and fix, @andralex ?

[andralex]

@nordlow just create a new PR. Thanks @JakobOvrum

[nordlow]

Ok, I can add the typeof(return) in it too.