• "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> (8/8) Feb 18 2014 I'm curious to why we need std.range.equal in cases such as
• bearophile (4/5) Feb 18 2014 In some cases I'd even like to use ~ instead of chain().
• Stanislav Blinov (4/5) Feb 18 2014 Range interface should be minimal. Don't forget that user types
• bearophile (7/8) Feb 18 2014 I agree. But I didn't mean to ask for that operator in the Range
• "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> (4/12) Feb 18 2014 Could you post the isChainable trait?
• "Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> (4/19) Feb 18 2014 Ahh, I guess you mean
• Stanislav Blinov (5/13) Feb 18 2014 1) opEquals cannot be a free function

"Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> writes:

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

"bearophile" <bearophileHUGS lycos.com> writes:

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

"Stanislav Blinov" <stanislav.blinov gmail.com> writes:

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.

"bearophile" <bearophileHUGS lycos.com> writes:

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

"Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> writes:

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 for my 
 nonstandard D1 library.

 Bye,
 bearophile

Could you post the isChainable trait?

I'm curious :)

/Per

"Per =?UTF-8?B?Tm9yZGzDtnci?= <per.nordlow gmail.com> writes:

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 a ~ 
 operator. It's easy to write a "chainable" trait. I did that 
 for my nonstandard D1 library.

 Bye,
 bearophile

 Could you post the isChainable trait?

 I'm curious :)

 /Per

Ahh, I guess you mean

http://forum.dlang.org/thread/bug-6043-3 http.d.puremagic.com%2Fissues%2F

/Per

"Stanislav Blinov" <stanislav.blinov gmail.com> writes:

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?

 /Per

1) opEquals cannot be a free function
2) there's no telling what opEquals does if Range defines it

IOW, equal() has a defined by-element-comparison semantics, while 
opEquals doesn't.