I know there is already a package available from atila neves about concepts, but despite being a neat workaround, it delivers not the full opportunities we know from type classes.

Why?
TypeClasses aren't a static solution only, they can also be used as existentials allowing dynamic dispatch implying that you can change the underlying implementation at runtime:
function(Concept c):Concept{...}

Further, implementing concepts over inner fields is limited, usually assoc functions are used (UFCS in case of D) which may can be covered with the concepts package of atila over dlang's compiletime reflection library "traits".
However, how instance resolution works then? Functions associated to types are local only, so if we import the concept from another module how can we check satisfyability if the needed ufcs/associated functions aren't imported likewise to the concept?

I know, introducing a new entity to existing entities like interfaces unnecessarily increases the complexity but how about reusing existing interfaces for that purpose?

For instance:

interface A
{
void method1();
}

interface B
{
void method2();
}

class C implements A //structural implements (valid D)
{
void method1() {...}
}

implement B for C //implement is a block keyword like class for posthoc implementation
{
method2(){...}
}

Another solution would be a pseudoclass:

class D implements B for C
{
method2(){...}
}

Now passing a C to B requires not only too look for C's definition but also for instances either globally in the project (preferred) or with special import for instances.

Another point to consider struct implementations via autoboxing, is it that hard to implement?
Also allowing fields in interfaces would complete the usefulness of concepts.

A possible look how flexible it can be taken from the nim language
Link:
https://nim-lang.org/docs/manual_experimental.html#concepts

I donna want to rant about D, I love it, really. But introducing classes separate to interfaces irks me and was in my eyes a failure from Java and all languages which follow them.

Why?
Because it introduces a biworld, both concepts overlap and you have to decide which to choose which is further complicated by availability of abstract classes, so why not unify all of them into a single concept?
Class methods were always default methods akin to default methods in interfaces and

and collision by multiple inheritance wasn't ever an issue which can be easily solved by scoping the super interfaces.
Another biworld are final classes and structs which seemingly equal in ther purpose, from a type theoretic viewpoint they represent the same type, so why have to version of the abstraction, choosing only structs as value or reference type would excitingly solve the issue.

Nevertheless, w can't changed everything in a backward-compatible way. I hope some of you are happy to discuss ideas about concepts in this thread.

On Sunday, 15 December 2019 at 13:06:52 UTC, sighoya wrote:
> I know there is already a package available from atila neves about concepts, but despite being a neat workaround, it delivers not the full opportunities we know from type classes.
>
> Why?
> TypeClasses aren't a static solution only, they can also be used as existentials allowing dynamic dispatch implying that you can change the underlying implementation at runtime:
> function(Concept c):Concept{...}
>
> Further, implementing concepts over inner fields is limited, usually assoc functions are used (UFCS in case of D) which may can be covered with the concepts package of atila over dlang's compiletime reflection library "traits".
> However, how instance resolution works then? Functions associated to types are local only, so if we import the concept from another module how can we check satisfyability if the needed ufcs/associated functions aren't imported likewise to the concept?
>
> I know, introducing a new entity to existing entities like interfaces unnecessarily increases the complexity but how about reusing existing interfaces for that purpose?
>
> For instance:
>
> interface A
> {
> void method1();
> }
>
> interface B
> {
> void method2();
> }
>
> class C implements A //structural implements (valid D)
> {
> void method1() {...}
> }
>
> implement B for C //implement is a block keyword like class for posthoc implementation
> {
> method2(){...}
> }
>
> Another solution would be a pseudoclass:
>
> class D implements B for C
> {
> method2(){...}
> }
>
> Now passing a C to B requires not only too look for C's definition but also for instances either globally in the project (preferred) or with special import for instances.
>
> Another point to consider struct implementations via autoboxing, is it that hard to implement?
> Also allowing fields in interfaces would complete the usefulness of concepts.
>
> A possible look how flexible it can be taken from the nim language
> Link:
> https://nim-lang.org/docs/manual_experimental.html#concepts
>
> I donna want to rant about D, I love it, really. But introducing classes separate to interfaces irks me and was in my eyes a failure from Java and all languages which follow them.
>
> Why?
> Because it introduces a biworld, both concepts overlap and you have to decide which to choose which is further complicated by availability of abstract classes, so why not unify all of them into a single concept?
> Class methods were always default methods akin to default methods in interfaces and

Dup of https://forum.dlang.org/post/tnzjbkdysfopowwmfzns@forum.dlang.org

Please delete this thread, it was misplaced.