I'm curious to why we need std.range.equal in cases such as
bool isPalindrome(Range)(in Range range) if
(isBidirectionalRange!Range)
{
return range.retro.equal(range);
}
Why isn't equality == operator used here instead?
/Per
Per Nordlöw:
Why isn't equality == operator used here instead?
In some cases I'd even like to use ~ instead of chain().
Bye,
bearophile
On Tuesday, 18 February 2014 at 09:31:55 UTC, Per Nordlöw wrote:
I'm curious to why we need std.range.equal in cases such as
bool isPalindrome(Range)(in Range range) if
(isBidirectionalRange!Range)
{
return range.retro.equal(range);
}
Why isn't equality == operator used here instead?
/Pe
On Tuesday, 18 February 2014 at 09:34:41 UTC, bearophile wrote:
In some cases I'd even like to use ~ instead of chain().
Range interface should be minimal. Don't forget that user types
can provide range interface and still benefit from operator
overloading for different purposes.
Stanislav Blinov:
Range interface should be minimal.
I agree. But I didn't mean to ask for that operator in the Range
protocol. I think some ranges should define a ~ operator. It's
easy to write a "chainable" trait. I did that for my nonstandard
D1 library.
Bye,
bearophile
On Tuesday, 18 February 2014 at 10:47:33 UTC, bearophile wrote:
Stanislav Blinov:
Range interface should be minimal.
I agree. But I didn't mean to ask for that operator in the
Range protocol. I think some ranges should define a ~ operator.
It's easy to write a "chainable" trait. I did that
On Tuesday, 18 February 2014 at 11:39:12 UTC, Per Nordlöw wrote:
On Tuesday, 18 February 2014 at 10:47:33 UTC, bearophile wrote:
Stanislav Blinov:
Range interface should be minimal.
I agree. But I didn't mean to ask for that operator in the
Range protocol. I think some ranges should define