Why not? ;)

I know you might want to hit me for bringing just another feature request inspired in Google's Go, but please do read it without preconceptions, because I think the features I'm suggesting are mostly already in D, but in a less convenient way.

With ranges, D is already using some kind of duck-typing. It's implemented
with template, template constraints and __traits(compiles)/is(typeof())
mostly. The range module makes extensive use of this trick.

All those features are great, and general and useful for a lot of things besides duck-typing. But (compile-time) duck-typing is a very nice feature which might deserve a little magic to avoid the boilerplate (or at least odd implementation).

What I'm suggesting is just some syntax sugar for compile-time duck-typing. My suggestion is to make this (a real example from the range module):

static interface InputRange(T) {
	bool empty();
	T front();
	void popFront();
}

size_t walkLength(InputRange range, size_t upTo = size_t.max)
{
	// implementation
}

struct Stride(T): InputRange(T) {
	// implementation
}


Be somehow equivalent to:

template isInputRange(R)
{
    enum bool isInputRange = is(typeof(
    {
        R r;
        if (r.empty) {}
        r.popFront;
        auto h = r.front;
    }()));
}

size_t walkLength(Range)(Range range, size_t upTo = size_t.max)
if (isInputRange!(Range))
{
	// implementation
}

struct Stride(T) if (isInputRange!(Range)) {
	// implementation
}


The former syntax is much pleasant for both defining 'static interfaces' and writing algorithms for them.

I didn't thought about this too much, and I'm sure there are plenty of holes to be worked out, but I wanted to throw the idea out there to see what people think about it.

What do you think?

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
I always get the feeling that when lesbians look at me, they're thinking,
'*That's* why I'm not a heterosexual.'
	-- George Constanza

Leandro Lucarella schrieb:

> What do you think?
> 

I like it.

Leandro Lucarella Wrote:

> static interface InputRange(T) {

Few days ago a professional C# programmer, a smart person that doesn't know much about D, has asked me if in D there are static interfaces. I think he was thinking about something similar.

I think that's a nice idea, or it can become a nice idea after some improvement.

Bye,
bearophile

Is there a reason not to have all interfaces compile time checked? It would still be allowable to state a class implements an interface and have the compiler check it.

The reason I say this is it would remove the complexity of having the two types of interfaces. And if you wanted to be able to check for the interface at run-time the same interface can be used.

Leandro Lucarella wrote:
> Why not? ;)

The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.

> static interface InputRange(T) {
> 	bool empty();
> 	T front();
> 	void popFront();
> }
> 
> size_t walkLength(InputRange range, size_t upTo = size_t.max)
> {
> 	// implementation
> }
> 
> struct Stride(T): InputRange(T) {
> 	// implementation
> }

Or just:

interface InputRange(T) {
	...
}

struct Stride(T) : InputRange(T) { ... }

size_t size_t walkLength(Range : InputRange)(Range range, ...

The main purpose of the interface is to allow the compiler to do some type checking.

(Interestingly, you could get an actual interface from a struct pointer. The compiler just needs to statically allocate a vtable (similar to a TypeInfo when writing typeid(T)). But I don't know if it'd be useful and is besides the point.)

Actually I'd prefer your proposal, because walkLength could access only members that are actually in InputRange. But the declaration looks too much like an untemplated function.

On the other hand, I remember that D2 once wanted to make this possible:

void foo(static int x, int y) { ... }

becomes

void foo(int x)(int y) { ... }

What happened to this? If it gets/got implemented, it would provide a nice opportunity to add syntax for such static interfaces.

grauzone wrote:
> Leandro Lucarella wrote:
>> Why not? ;)
> 
> The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.

There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.

FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection.


Andrei

Andrei Alexandrescu wrote:
> grauzone wrote:
>> Leandro Lucarella wrote:
>>> Why not? ;)
>>
>> The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.
> 
> There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.

That's understandable of course.

> FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection.

That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done.

Which are the problems you mentioned?

> 
> Andrei

grauzone wrote:
> Andrei Alexandrescu wrote:
>> grauzone wrote:
>>> Leandro Lucarella wrote:
>>>> Why not? ;)
>>>
>>> The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.
>>
>> There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.
> 
> That's understandable of course.
> 
>> FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection.
> 
> That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done.
> 
> Which are the problems you mentioned?

I knew this was going to be asked. One issue I remember was that it's difficult to talk about "a struct must define a type with certain properties". You will say "but you can express that type as another interface" but that solves the problem by increasing the size of the feature. It gets even more complicated when you want to say "defines a type with these or these other properties, depending on the properties of this type parameter." I think that all can be solved through something that is very similar to C++ concepts, and I would want to avoid going that route.

Andrei

Andrei Alexandrescu wrote:
> grauzone wrote:
>> Andrei Alexandrescu wrote:
>>> grauzone wrote:
>>>> Leandro Lucarella wrote:
>>>>> Why not? ;)
>>>>
>>>> The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.
>>>
>>> There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.
>>
>> That's understandable of course.
>>
>>> FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection.
>>
>> That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done.
>>
>> Which are the problems you mentioned?
> 
> I knew this was going to be asked. One issue I remember was that it's difficult to talk about "a struct must define a type with certain properties". You will say "but you can express that type as another interface" but that solves the problem by increasing the size of the feature. It gets even more complicated when you want to say "defines a type with these or these other properties, depending on the properties of this type parameter." I think that all can be solved through something that is very similar to C++ concepts, and I would want to avoid going that route.

In other words, a general solution inside the language would be too complex (because it had to support all sorts of type interfaces), so you'll just leave it to the user, who will implement the same thing with is() and friends?

> Andrei

grauzone wrote:
> Andrei Alexandrescu wrote:
>> grauzone wrote:
>>> Andrei Alexandrescu wrote:
>>>> grauzone wrote:
>>>>> Leandro Lucarella wrote:
>>>>>> Why not? ;)
>>>>>
>>>>> The actual question is if Andrei/Walter are interested at all in this. Because they didn't show any interest so far. D will probably be doomed to compile time bug-typing I mean duck-typing forever.
>>>>
>>>> There's an embarrassment of riches when it comes to finding stuff to work on for D2. I think we need to resign ourselves to the idea that we need to focus only on one subset of the stream of good ideas that are being proposed.
>>>
>>> That's understandable of course.
>>>
>>>> FWIW I was keen on structs interacting in interesting ways with interfaces (and submitted a number of enhancements in that directions) but then realized there are a number of problems that structs/interfaces cannot solve. I believe that a better path to pursue in checking interface conformance is via reflection.
>>>
>>> That's a possible solution (and an easy way out to get rid of language design problems), but I'm sure it's not the best solution. (It also should be a little bit extended to give the user better error messages.) I hope cleaner solutions will be considered later, possibly after D2 is done.
>>>
>>> Which are the problems you mentioned?
>>
>> I knew this was going to be asked. One issue I remember was that it's difficult to talk about "a struct must define a type with certain properties". You will say "but you can express that type as another interface" but that solves the problem by increasing the size of the feature. It gets even more complicated when you want to say "defines a type with these or these other properties, depending on the properties of this type parameter." I think that all can be solved through something that is very similar to C++ concepts, and I would want to avoid going that route.
> 
> In other words, a general solution inside the language would be too complex (because it had to support all sorts of type interfaces), so you'll just leave it to the user, who will implement the same thing with is() and friends?

I don't think that's a fair characterization. With reflection you can implement such capability in a library. Sometimes a motivated and well-intended feature could grow into a monster of generalization. This is what happened to C++ concepts and what could have happened to typedef if we hadn't clipped it.

Andrei