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