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.
