[Dlang-internal] Is there any chance to introduce concepts/traits/typeClasses in dlang?

[sighoya]

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.