The Sparrow language

[Puming via Digitalmars-d]

On Wednesday, 6 April 2016 at 20:42:27 UTC, Lucian Radu 
Teodorescu wrote:
> On Wednesday, 6 April 2016 at 14:54:18 UTC, Puming wrote:
>> On Wednesday, 6 April 2016 at 13:15:48 UTC, Andrei 
>> Alexandrescu wrote:
>>> [...]
>>
>> Interesting. I've thinking about concepts too. Hopefully they 
>> could come into D. Actually, I think concept and interfaces 
>> could be combined into one feature. An interface is just a 
>> special case of a concept, saying its implementer should have 
>> the matching function signatures.
>
> In my opinion implementing concepts in terms of interfaces is 
> more restrictive than implementing them as boolean predicates. 
> You cannot create interfaces based on existence of attributes, 
> on existence of dependent types or on the existence of extern 
> function that apply to your types. Moreover, you cannot create 
> concepts based on the compile-time values associated with your 
> type.

Well, I meant the opposite, interfaces be implemented with 
concept.
So in my opinion, interface is just a spcecial case of concept.
I'm in the same park with you.
See 
https://github.com/venus-lang/venus/blob/master/docs/reference/trait.md where I call concept 'trait'.

>
> One basic example, from C++, is that you cannot create a 
> concept that distinguishes between vector<int> and 
> vector<bool>, as they theoretically should have the same 
> interface.
>
> The main uses of concepts are in my view most of the time 
> related to dependent types. I would like to have an InputRange 
> concept that will also tell me the type of the elements I can 
> read from it.
>

Exactly, that is well I found InputRange in D awkward, where I 
have to specify a long predicate everywhere in my function 
definiations of a call chain.

> Implementing concepts as predicates, give you much more 
> freedom. I would argue that you can represent many more 
> concepts with predicates. Not only you can represent all the 
> "has-a" relations, but you can also place conditions on the 
> compile-time values that your types might have, and how that 
> class may be used.
>
Yes, indeed.
> My two cents,
> LucTeo