An example of typeclasses/traits/protocols/concepts in D with interfaces

[sighoya]

On Wednesday, 23 December 2020 at 23:21:47 UTC, rikki cattermole 
wrote:
> I prefer the original name, signatures and to ditch the 
> nastiness that is classes (which do everything wrong for best 
> practice OOP).
>
> https://gist.github.com/rikkimax/826e1c4deb531e8dd993815bf914acea#signatures

Could you elaborate a bit more about the signature details, when 
does an implementation (is it any kind of type except signature?) 
conform to the signature.

Conformity by structurality or by an indirect instance?

The former variant is known as structural typing, the best type 
system known for this is ocaml, and they already use the name 
`signature` for it, so it would already fit.
See: 
https://www.cs.cornell.edu/courses/cs3110/2020fa/textbook/modules/signatures.html

Note, there is an experimental feature to allow for structuralism 
with structs and interfaces
See: https://dlang.org/phobos/std_experimental_typecons.html

I want that too together with an operator opImplicitCoerce or 
opImplicitConvert (that was already proposed by someone else 
here) allowing implicit coercion/conversion when passing structs 
to callees expecting conforming interfaces.

An implicit operator is much more powerful than alias this which 
is coupled to an source type, the operator is decoupled.

I don't know what the state is with this extension and why it is 
over years still experimental...


The latter is known as typeclasses/traits/protocols. It is more 
powerul as a type can match even when their names doesn't equal 
the names in the typeclass, but the drawback is you have to pass 
an indirect impl to each function using typeclasses.
I have proposed a way to do it semi-automatically either by 
templates or by a default value s.t. not at every time at the 
callsite an implementation has to be passed into the callee.

Note, with an implicit conversion operator, we could also pass 
implicitly the typeclass instance in the conversion operation at 
the call site but that would ,sadly, only cover the non generic 
case.

I think that there is a big resistance in the D community 
regarding the introduction of new concepts, therefore reusing 
interfaces may be an acceptable way to go eventually by 
supporting to pass instances implicitly in the generic case, I 
don't know.

I think we would also need to enhance the overload resolution for 
concrete types s.t. the method is preferred which matches either 
exactly or there is an implicit order of conversions yielding the 
narrowest method, i.e. the method for which all types parameters 
of it are convertible in order to all other types of each method.

It would reduce ambiguity akin to Walthers fear about multiple 
inheritance a lot.
And if we have ambiguity we just add another method which 
intersects all the parameter types of all the methods in order if 
the types are interfaces or classes or any other existential, 
otherwise we have to add a method with an exact match.

It would require intersection types though, but I think we can 
construct them by templates?