Robert Fraser Wrote:

> Steve Teale wrote:
> > template isInputRange(R)
> > {
> >     enum bool isInputRange = is(typeof(
> >     {
> >         R r;             // can define a range object
> >         if (r.empty) {}  // can test for empty
> >         r.popFront;          // can invoke next
> >         auto h = r.front; // can get the front of the range
> >     }()));
> > }
> > 
> > I can not possibly be the only D enthusiast who finds this completely incomprehensible.
> 
> Yeah, that one is a bit tricky, and what makes it worse is that it seems officially sanctioned by Walter/Andrei as the "right way" to check if a type supports some operations. Basically, if you have:
> 
> is(typeof({ @@@ }()));
> 
> this means "if I made a function containing @@@, would that function compile?". It's a hack which stems from the way the is expression works.
> 
> > What is a range?
> 
> As others have mentioned, it's just a struct (or other type) that happens to support certain operations.

So does this mean that interfaces are just a tragic mistake. I'd always thought that what you said was a pretty good description of what an interface is!

Steve Teale wrote:
...
> Robert Fraser Wrote:
>> As others have mentioned, it's just a struct (or other type) that happens to support certain operations.
> 
> So does this mean that interfaces are just a tragic mistake. I'd always thought that what you said was a pretty good description of what an interface is!

Could you explain why that makes interfaces a mistake? Interfaces (as in classes implementing an interface) do provide dynamic polymorphism which these compile time constraints (or 'concepts' in STL terms) don't.

Steve Teale wrote:
> Robert Fraser Wrote:
> 
>> Steve Teale wrote:
>>> template isInputRange(R)
>>> {
>>>     enum bool isInputRange = is(typeof(
>>>     {
>>>         R r;             // can define a range object
>>>         if (r.empty) {}  // can test for empty
>>>         r.popFront;          // can invoke next
>>>         auto h = r.front; // can get the front of the range
>>>     }()));
>>> }
>>>
>>> I can not possibly be the only D enthusiast who finds this completely incomprehensible. 
>> Yeah, that one is a bit tricky, and what makes it worse is that it seems officially sanctioned by Walter/Andrei as the "right way" to check if a type supports some operations. Basically, if you have:
>>
>> is(typeof({ @@@ }()));
>>
>> this means "if I made a function containing @@@, would that function compile?". It's a hack which stems from the way the is expression works.
>>
>>> What is a range?
>> As others have mentioned, it's just a struct (or other type) that happens to support certain operations.
> 
> So does this mean that interfaces are just a tragic mistake. I'd always thought that what you said was a pretty good description of what an interface is!
> 

IMHO, duck-typing in D is a tragic mistake...  This should have been implemented with compile time interfaces.

Yigal Chripun wrote:
...
> 
> IMHO, duck-typing in D is a tragic mistake...  This should have been implemented with compile time interfaces.

Care to provide arguments?

Lutger Wrote:

> Yigal Chripun wrote:
> ...
> > 
> > IMHO, duck-typing in D is a tragic mistake...  This should have been implemented with compile time interfaces.
> 
> Care to provide arguments?

ignorance 'n' arrogance should do.

superdan wrote:

> Lutger Wrote:
> 
>> Yigal Chripun wrote:
>> ...
>> > 
>> > IMHO, duck-typing in D is a tragic mistake...  This should have been implemented with compile time interfaces.
>> 
>> Care to provide arguments?
> 
> ignorance 'n' arrogance should do.

Those I hold I high esteem, you convinced me.

Lutger wrote:
> Yigal Chripun wrote:
> ...
>> IMHO, duck-typing in D is a tragic mistake...  This should have been
>> implemented with compile time interfaces.
> 
> Care to provide arguments?
> 
> 

duck typing makes more sense in dynamic languages like Ruby which is famous for it.

in static languages I as a user prefer to trade flexibility due to duck-typing for compile time checks.

yes, at compile time, duck typing and (compile-time) interfaces are basically the same thing, but since the rest of the language uses formal interfaces, it is more consistent (and easier to understand) to use the same approach at compile-time as well. point in case, look how much unnecessary confusion Ranges cause which would be eliminated had D allowed for compile-time interfaces.
i.e.
Interface I { .. }
struct S : I { ... }
this is basically the same as C++ concepts only without redundant and confusing syntax.

templates are hard for users to understand and one of the main reasons for this is that templates are essentially a completely different language with different syntax and semantics which to me looks like mis-design.

Yigal Chripun:
> point in case, look how much unnecessary confusion Ranges cause which would be eliminated had D allowed for compile-time interfaces.

What are interfaces from the point of view of the compiler?

Bye,
bearophile
(P.S.: Is Walter around still? He's pretty silent lately. Talking when he's not around looks quite academic).

Yigal Chripun Wrote:

> Lutger wrote:
> > Yigal Chripun wrote:
> > ...
> >> IMHO, duck-typing in D is a tragic mistake...  This should have been implemented with compile time interfaces.
> > 
> > Care to provide arguments?
> > 
> > 
> 
> duck typing makes more sense in dynamic languages like Ruby which is famous for it.

yer didnt say why & this adds nutt'n'.

> in static languages I as a user prefer to trade flexibility due to duck-typing for compile time checks.

yer dunno what yer talking about do ya. d checks duck typed shit at compile time.

> yes, at compile time, duck typing and (compile-time) interfaces are
> basically the same thing, but since the rest of the language uses formal
> interfaces, it is more consistent (and easier to understand) to use the
> same approach at compile-time as well. point in case, look how much
> unnecessary confusion Ranges cause which would be eliminated had D
> allowed for compile-time interfaces.
> i.e.
> Interface I { .. }
> struct S : I { ... }
> this is basically the same as C++ concepts only without redundant and
> confusing syntax.

& how do ya figure tat I defines a type elementtype?

> templates are hard for users to understand and one of the main reasons for this is that templates are essentially a completely different language with different syntax and semantics which to me looks like mis-design.

2 me looks like yer in way over yer head.

== Quote from bearophile (bearophileHUGS@lycos.com)'s article
> Yigal Chripun:
> > point in case, look how much
> > unnecessary confusion Ranges cause which would be eliminated had D
> > allowed for compile-time interfaces.
> What are interfaces from the point of view of the compiler?

Abstract classes with only pure virtual functions.  In other words, basically under the hood, an interface is just the layout of a vtable.

This actually leads to a comment I want to make in the wider debate:  I personally find explicit interfaces really, really annoying and I think that duck typing is by far the most intuitive type system there is.  I used to program primarily in duck typed languages and resort to every kludge imaginable for speed.  What attracted me to D was that the templates and type inference are so powerful that I almost feel like it's still a duck typed language, but much faster and with more error checking.  I guess that's why I like ranges so much.

Also, while the fact that you need interfaces to specify a vtable layout is an implementation detail, I would argue that, in close to the metal languages, it does more harm than good to try too hard to prevent implementation details from leaking into the language abstractions.  Otherwise, what would be the point of it being a close to the metal language?  The fact that, for templates, one does not need to specify vtable layouts and for OO you do justifies the asymmetry between templates and OO.  Interfaces for templates would just add boilerplate and make explicit something that is already implicitly knowable and checked at compile time anyhow.