C++ guys hate static_if?

[TommiT]

On Tuesday, 12 March 2013 at 15:10:25 UTC, deadalnix wrote:
> On Tuesday, 12 March 2013 at 14:16:15 UTC, H. S. Teoh wrote:
>> On Tue, Mar 12, 2013 at 12:39:48PM +0100, TommiT wrote:
>>> On Tuesday, 12 March 2013 at 04:34:05 UTC, Walter Bright 
>>> wrote:
>>> >It's interfaces without the vtable[].
>>> >
>>> >It's still solely based on type signatures. D constraints 
>>> >make
>>> >pretty much anything that can be computed at compile time a
>>> >testable gate.
>>> 
>>> Yeah, you're right. That kind of interface syntax doesn't 
>>> really
>>> lend itself to specifying concepts. So, here's another 
>>> attempt at
>>> a concept syntax (and functionality):
>>> 
>>> concept AscendingInfiniteInputRange {
>>>     // 'this' is an instance of a type which implements the
>>>     // AscendingInfiniteInputRange concept given the
>>>     // if-condition below is true:
>>>     if( is(typeof(this.empty) : bool)
>>>     &&  is(typeof(this.front))
>>>     && !is(typeof(this.front) == void)
>>>     &&  is(typeof(this.popFront() == void)
>>>     // testing a compile time evaluable value:
>>>     &&  this.empty == false
>>>     // static members can also be tested:
>>>     &&  typeof(this).infinite == true
>>>     &&  typeof(this).sortedAscending == true )
>>> }
>>
>> How is this any different from the current isInputRange!R,
>> isForwardRange!R, etc.?
>>
>>
>> T
>
> With the thing defined that way not that much. But consider :
>
> concept InputRange(T) {
>     bool empty;
>     T front;
>     void popFront();
> }

What if I write a type like the following:

struct MyType {
     int _value;

     @property bool empty() const { return true; }
     @property ref const(int) front() const { return _value; }
     void popFront() const { }
}

Does MyType fulfill the requirements of your InputRange(T) 
concept? I don't think it does since its front returns by ref 
const(int) and InputRange(T)'s front returns by value.