09-Mar-2013 05:19, Brad Anderson пишет:
> On Saturday, 9 March 2013 at 00:48:59 UTC, DypthroposTheImposter wrote:
>>        See the static_if paper here:
>>
>> http://isocpp.org/forums
>>
>> Under the post "constraints and static if" there is a link to a
>> document about
>> static_if
>>
>> https://docs.google.com/viewer?a=v&pid=forums&srcid=MDIyMDc3NjUwMTczOTM0Mjk3NjABMDI2MzM3MjkxNDM4NDQ5MzE4NDcBLWVsS1Y4dFhtdDhKATUBaXNvY3BwLm9yZwF2Mg
>>
>>
>>       Are they full of it? Has it caused the problems they mention
>> in
>> D?
>
> Well, the two guys with an alternative proposal (concepts-lite) seem to
> hate static if (along with a third guy).
>

In fact I'd *love* for C++ to take the concepts-lite path.

Why?
Because then we can see how it works out for them and probably steal some ideas, of course, porting the to D's static if workhorse. C++14 is just around the corner if they are actually able to ship standards that fast (as they plan).

And even if concepts is a failure... well, it's C++ - I couldn't care less :)

-- 
Dmitry Olshansky

On 3/12/2013 12:13 AM, deadalnix wrote:
> On Tuesday, 12 March 2013 at 06:34:50 UTC, Walter Bright wrote:
>> Not for infinite ranges, which depend on empty returning a compile time value.
> It was already discussed int he past that this was a bad idea. I think that is
> another symptom of that poor design choice than an actual issue with concepts.

Nevertheless, it shows a weakness of concepts in that concepts are unable to express ideas about values - only types.

On Tuesday, 12 March 2013 at 07:59:49 UTC, monarch_dodra wrote:
> On Tuesday, 12 March 2013 at 07:13:11 UTC, deadalnix wrote:
>> On Tuesday, 12 March 2013 at 06:34:50 UTC, Walter Bright wrote:
>>> Not for infinite ranges, which depend on empty returning a compile time value.
>>
>> It was already discussed int he past that this was a bad idea. I think that is another symptom of that poor design choice than an actual issue with concepts.
>
> When was it discussed that this was a bad idea?
>
> I'm not saying it isn't (I think it isn't), but I don't remember any such discussion. I'd love to read it.

http://forum.dlang.org/thread/yjogdvimxeyxzrjoqzsr@forum.dlang.org

First answer is yours, BTW :D

On 3/12/2013 1:14 AM, deadalnix wrote:
> On Tuesday, 12 March 2013 at 07:59:49 UTC, monarch_dodra wrote:
>> On Tuesday, 12 March 2013 at 07:13:11 UTC, deadalnix wrote:
>>> On Tuesday, 12 March 2013 at 06:34:50 UTC, Walter Bright wrote:
>>>> Not for infinite ranges, which depend on empty returning a compile time value.
>>>
>>> It was already discussed int he past that this was a bad idea. I think that
>>> is another symptom of that poor design choice than an actual issue with
>>> concepts.
>>
>> When was it discussed that this was a bad idea?
> http://forum.dlang.org/thread/yjogdvimxeyxzrjoqzsr@forum.dlang.org

I don't think that thread conclusively determined it was a bad idea.

On Tuesday, 12 March 2013 at 09:35:51 UTC, Walter Bright wrote:
> On 3/12/2013 1:14 AM, deadalnix wrote:
>> On Tuesday, 12 March 2013 at 07:59:49 UTC, monarch_dodra wrote:
>>> On Tuesday, 12 March 2013 at 07:13:11 UTC, deadalnix wrote:
>>>> On Tuesday, 12 March 2013 at 06:34:50 UTC, Walter Bright wrote:
>>>>> Not for infinite ranges, which depend on empty returning a compile time value.
>>>>
>>>> It was already discussed int he past that this was a bad idea. I think that
>>>> is another symptom of that poor design choice than an actual issue with
>>>> concepts.
>>>
>>> When was it discussed that this was a bad idea?
>> http://forum.dlang.org/thread/yjogdvimxeyxzrjoqzsr@forum.dlang.org
>
> I don't think that thread conclusively determined it was a bad idea.

The thread don't conclude anything. It nevertheless raises very good points.

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 )
}

// extending the AscendingInfiniteInputRange concept:
concept AscendingInfiniteForwardRange
       : AscendingInfiniteInputRange
{
     if (is(typeof(this.save) == typeof(this)))
}

// a concept of a 2-dimensional infinite ascending slope:
concept InfiniteSlope : AscendingInfiniteForwardRange {
     // 'is' can be used to test if a type implements a concept:
     if (is(typeof(this.front) == AscendingInfiniteForwardRange))
}

On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
> struct S1 implements A2 {
>     void foo() { }
>     void bar() { }
> }

That's not good. Types shouldn't have to explicitly say that they implement a concept. The fact that a type implements a concept should be implicit, i.e. the following (pseudo-code) should work:

concept InputRange {
    if( is(typeof(this.empty) : bool)
    &&  is(typeof(this.front))
    &&  is(typeof(this.popFront() == void) )
}

struct MyRange {
    bool empty() { return false; }
    int  front() { return 42; }
    void popFront() { }
}

void main() {
    static assert(is(MyRange == InputRange));
}

On Tue, 12 Mar 2013 12:51:03 +0100
"TommiT" <tommitissari@hotmail.com> wrote:

> On Tuesday, 12 March 2013 at 02:39:06 UTC, TommiT wrote:
> > struct S1 implements A2 {
> >     void foo() { }
> >     void bar() { }
> > }
> 
> That's not good. Types shouldn't have to explicitly say that they implement a concept.

I *strongly* disagree. A much as I love ranges (for example), their duckiness is the one thing I consider to be a huge mistake.

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

-- 
Дерево держится корнями, а человек - друзьями.

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

The difference is in function overload resolution. Polymorphic concept based template would know about the hierarchical nature of the concepts, say ForwardRange is a sub-concept of InputRange, and thus the function overload resolution would be able to choose the template which has the most derived/specialized concept parameter that still matches with the given template argument.