www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why does D not have generics?

reply Q. Schroll <qs.il.paperinik gmail.com> writes:
I don't want to be mistaken. I know what the differences of 

Maybe my question has obvious answers and I just don't see them.

The only programming language I know of that has both, templates 
and generics, is C++/CLI and ones closely related.


have generics. Templates can be used in some use cases, templates 
have their specific use cases (like DbI). What seems to never 
mentioned is that generics have their specific use cases, too.

What I may be missing, is how Java-esce generics can be 
implemented using D's templates (without much effort). What I'd 
expect from generics is this:

A generic class or interface states its requirements (base 
classes, interfaces, [never seen in the wild:] subclasses, ...) 
to its type parameters exactly. Everything that is part of the 
implementation is checked when the generic aggregate is defined. 
It is not necessary to instantiate a rainbow of types to be sure 
the implementation is valid for every kind of type parameter the 
programmer intends to support.

Generics allow for implicit conversion by covariance and 

to its covariant or contravariant part-interface (that is a 
supertype of the interface, really). (Java [2, 3])

Generics are really great for specifying the expectations of your 
type parameters' requirements and letting the compiler make sure 
the requirements suffice to allow for the stuff you want to work.
Using templates, the compiler checks requirements only for 
specific instances. It might be that the requirements are 
insufficient, but because no test tried the potentially very 
specific type argument, it will be unrecognized.

Also, one feature D doesn't have, is expressing the precise union 
or intersection of interfaces: Say you have two interfaces I and 
J. The interface (I & J) has all the methods specified by any of 
them. A class that implements I and J automatically implements (I 
& J). The interface (I | J) has all the methods specified by both 
of them. A class that implements I or implements J automatically 
implements (I | J). If you e.g. iterate an (I | J)[] object, you 
can call any method required by both interfaces. (Typescript [4])
It might be hard or even impossible to implement this using 
vtables and stuff.

In D, one can easily create templates intersectInterface(Is...) 
and unionInterface(Is...) that basically do that.

It could very well be that D doesn't have them because they have 
to be implemented and maintained, and the cost/benefit ratio 
wasn't good enough. Maybe they can be implemented in a library 
rather easily. I know that me failing to do that doesn't prove 
it's impossible or even hard.

[1] 
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/covariance-contravariance/variance-in-generic-interfaces
[2] 
https://docs.oracle.com/javase/tutorial/java/generics/lowerBounded.html
[3] 
https://docs.oracle.com/javase/tutorial/java/generics/upperBounded.html
[4] 
https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html?ref=hackernoon.com
Jan 11
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 11 January 2021 at 18:23:20 UTC, Q. Schroll wrote:
 I don't want to be mistaken. I know what the differences of 

 are. Maybe my question has obvious answers and I just don't see 
 them.

 The only programming language I know of that has both, 
 templates and generics, is C++/CLI and ones closely related.
I think you are really talking about generics in Java and is interpreting the semantic landscape through that lense? There are many variations: https://en.wikipedia.org/wiki/Generic_programming C++ "concepts" is to a large extent syntactical sugar that makes it easier to specify interfaces... so I don't think it has a significant semantic impact. Mostly a usability impact.
Jan 11
parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Monday, 11 January 2021 at 18:30:19 UTC, Ola Fosheim Grøstad 
wrote:
 On Monday, 11 January 2021 at 18:23:20 UTC, Q. Schroll wrote:
 I don't want to be mistaken. I know what the differences of 

 are. Maybe my question has obvious answers and I just don't 
 see them.

 The only programming language I know of that has both, 
 templates and generics, is C++/CLI and ones closely related.
I think you are really talking about generics in Java and is interpreting the semantic landscape through that lense?
Yes. But I'm not saying: Do exactly as Java does. I'm saying: Java has this very interesting concept that D might want to learn, too.
 C++ "concepts" is to a large extent syntactical sugar that 
 makes it easier to specify interfaces... so I don't think it 
 has a significant semantic impact. Mostly a usability impact.
You might have mistaken me. C++ has no generics in the sense I meant. Generics to me means not that List<A> and List<B> result in one List type; really, I care about much more semantics than digress, because I don't care. type (which you can and entails a template-like implementation under the hood), the compiler makes sure that everything in your generic type is semantically valid for every type argument satisfying the conditions you state. For example, if you call T.method(), but no constraint says that T.method() exists, the compiler rejects the code. On the other hand, in C++ or D, if you call T.method() in a template and only test types that happen to have method(), everything is good between friends (Andrei's quote). I'm not arguing you *always* want static checks, obviously DbI hardly works that way. All I'm saying is, the big thing generics would bring to D is **statically ensuring** that the requirements put on type parameters suffice for the implementation to be valid.
Jan 12
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 16:57:43 UTC, Q. Schroll wrote:
 Yes. But I'm not saying: Do exactly as Java does. I'm saying: 
 Java has this very interesting concept that D might want to 
 learn, too.
Right. D has to chose something that blends well with what is already there. :-) But I actually think that the semantics for this are there, but the syntax is lacking, but maybe I misunderstand what you want.
 For example, if you call T.method(), but no constraint says 
 that T.method() exists, the compiler rejects the code. On the 
 other hand, in C++ or D, if you call T.method() in a template 
 and only test types that happen to have method(), everything is 
 good between friends (Andrei's quote).
But I don't quite see how this is different from C++ concepts, which basically is better syntax for testing traits of types provided through parameters/methods.
 I'm not arguing you *always* want static checks, obviously DbI 
 hardly works that way. All I'm saying is, the big thing 
 generics would bring to D is **statically ensuring** that the 
 requirements put on type parameters suffice for the 
 implementation to be valid.
Yes, I certainly agree that this is desirable. I just don't understand what semantics are missing. I think D has this? Just not the syntax?
Jan 12
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 12 January 2021 at 17:12:11 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 12 January 2021 at 16:57:43 UTC, Q. Schroll wrote:
 For example, if you call T.method(), but no constraint says 
 that T.method() exists, the compiler rejects the code. On the 
 other hand, in C++ or D, if you call T.method() in a template 
 and only test types that happen to have method(), everything 
 is good between friends (Andrei's quote).
But I don't quite see how this is different from C++ concepts, which basically is better syntax for testing traits of types provided through parameters/methods.
C++ concepts, as far as I'm aware, don't cause templates to be checked for conformance prior to instantiation--which is what's being asked for here. For that, you'd need something more like Rust's traits.
Jan 12
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 17:16:19 UTC, Paul Backus wrote:
 C++ concepts, as far as I'm aware, don't cause templates to be 
 checked for conformance prior to instantiation--which is what's 
 being asked for here. For that, you'd need something more like 
 Rust's traits.
Not sure what you mean? C++ use SFINAE. If it fails it will look elsewhere.
Jan 12
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 12 January 2021 at 17:17:40 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 12 January 2021 at 17:16:19 UTC, Paul Backus wrote:
 C++ concepts, as far as I'm aware, don't cause templates to be 
 checked for conformance prior to instantiation--which is 
 what's being asked for here. For that, you'd need something 
 more like Rust's traits.
Not sure what you mean? C++ use SFINAE. If it fails it will look elsewhere.
As far as I'm aware, C++ does not prevent you from writing code like this: template<typename T> concept MyConcept = requires (T t) { T.foo(); }; template<MyConcept T> void fun(T t) { t.bar(); } In Java or Rust, the above would be a compile-time error.
Jan 12
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 17:32:17 UTC, Paul Backus wrote:
 template<MyConcept T>
 void fun(T t) { t.bar(); }

 In Java or Rust, the above would be a compile-time error.
Ok, I get what you say. Concepts is more for library implementors than applications, so it is assumed the library implementor knows what he is doing, and the focus is on putting restrictions on library usage. But you can do that in C++ to some extent. You can remove members from a declaration, even though they are present in the definition. Thanks to header files and reinterpret casting. There is a lot of stuff you can do in C++ (but not really recommended).
Jan 12
parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 12 January 2021 at 17:43:39 UTC, Ola Fosheim Grøstad 
wrote:
 But you can do that in C++ to some extent. You can remove 
 members from a declaration, even though they are present in the 
 definition. Thanks to header files and reinterpret casting. 
 There is a lot of stuff you can do in C++ (but not really 
 recommended).
You can do it in D too, if you use an interface or a type-erasure library like Atila's tardy. But it requires additional runtime overhead compared to the loosely-checked template version. In Rust, on the other hand, you get strict type checking of generic code with zero overhead at runtime.
Jan 12
parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 12 January 2021 at 17:52:16 UTC, Paul Backus wrote:
 You can do it in D too, if you use an interface or a 
 type-erasure library like Atila's tardy. But it requires 
 additional runtime overhead compared to the loosely-checked 
 template version. In Rust, on the other hand, you get strict 
 type checking of generic code with zero overhead at runtime.
I'll have a closer look at Tardy. I previously misunderstood it to be a different language and not a DUB package. Thank you.
Jan 12
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
So, this is one, perhaps clumsy way of doing it:


import std.stdio;

struct StackConcept(T,E) {
     alias self_type = T;
     alias element_type = E;
	T* self;
     this(T* obj){ self = obj; }
     pragma(inline,true) void push(E x){ self.push(x); }
     pragma(inline,true) E pop(){ return self.pop(); }
}

template is_StackConcept(T) {
     enum bool is_StackConcept = 
is(StackConcept!(T.self_type,T.element_type)==T);
}

struct intstack {
     int[] arr = [];
     void push(int x){ arr.length++; arr[$-1] = x; }
     int pop(){ auto tmp=arr[$-1]; arr.length--; return tmp; }

     auto as_StackConcept(){
     	return StackConcept!(intstack,int)(&this);
	}
}

auto pop_second(T)(T* obj){
     auto stack = obj.as_StackConcept();
     static assert (is_StackConcept!(typeof(stack)));
	auto tmp = stack.pop();
     auto tmp2 = stack.pop();
     stack.push(tmp);
     return tmp2;
}

void main()
{
     intstack stack;
     stack.push(1);
     stack.push(2);
     stack.push(3);
     pop_second(&stack);
     writeln(stack.pop());
     writeln(stack.pop());
}
Jan 12
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 21:32:46 UTC, Ola Fosheim Grøstad 
wrote:
 auto pop_second(T)(T* obj){
     auto stack = obj.as_StackConcept();
     static assert (is_StackConcept!(typeof(stack)));
 	auto tmp = stack.pop();
     auto tmp2 = stack.pop();
     stack.push(tmp);
     return tmp2;
 }
An improvement is to define a helper function: auto as_stack(T)(T* obj){ auto stack = obj.as_StackConcept(); static assert (is_StackConcept!(typeof(stack))); return stack; } Then you can just do: auto pop_second(T)(T* obj){ auto stack = obj.as_stack(); auto tmp = stack.pop(); auto tmp2 = stack.pop(); stack.push(tmp); return tmp2; } Or: auto pop_second(T)(T* obj){ auto tmp = obj.as_stack.pop(); auto tmp2 = obj.as_stack.pop(); obj.as_stack.push(tmp); return tmp2; }
Jan 12
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 12 January 2021 at 21:32:46 UTC, Ola Fosheim Grøstad 
wrote:
 So, this is one, perhaps clumsy way of doing it:
[...]
 auto pop_second(T)(T* obj){
     auto stack = obj.as_StackConcept();
     static assert (is_StackConcept!(typeof(stack)));
 	auto tmp = stack.pop();
     auto tmp2 = stack.pop();
     stack.push(tmp);
     return tmp2;
 }
You have written a generic function that accepts any type (unconstrained `T`), but fails to instantiate for most of them (e.g. `pop_second!int` would not compile). In a language like Rust or Java with type-checked generics, the compiler would reject this function definition.
Jan 12
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 22:23:51 UTC, Paul Backus wrote:
 You have written a generic function that accepts any type 
 (unconstrained `T`), but fails to instantiate for most of them 
 (e.g. `pop_second!int` would not compile). In a language like 
 Rust or Java with type-checked generics, the compiler would 
 reject this function definition.
Hm? pop_second requires StackConcept!(T,E) ?
Jan 12
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 22:29:09 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 12 January 2021 at 22:23:51 UTC, Paul Backus wrote:
 You have written a generic function that accepts any type 
 (unconstrained `T`), but fails to instantiate for most of them 
 (e.g. `pop_second!int` would not compile). In a language like 
 Rust or Java with type-checked generics, the compiler would 
 reject this function definition.
Hm? pop_second requires StackConcept!(T,E) ?
Works fine for me: void push(int* x, bool b){ *x = (*x<<1)|b; } bool pop(int* x){ bool tmp = *x&1; *x=*x>>1; return tmp; } auto as_StackConcept(int* x){ return StackConcept!(int,bool)(x);} void main() { int stack = 5; pop_second(&stack); writeln(pop(&stack)); writeln(pop(&stack)); }
Jan 12
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 12 January 2021 at 22:41:03 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 12 January 2021 at 22:29:09 UTC, Ola Fosheim 
 Grøstad wrote:
 On Tuesday, 12 January 2021 at 22:23:51 UTC, Paul Backus wrote:
 You have written a generic function that accepts any type 
 (unconstrained `T`), but fails to instantiate for most of 
 them (e.g. `pop_second!int` would not compile). In a language 
 like Rust or Java with type-checked generics, the compiler 
 would reject this function definition.
Hm? pop_second requires StackConcept!(T,E) ?
Works fine for me: void push(int* x, bool b){ *x = (*x<<1)|b; } bool pop(int* x){ bool tmp = *x&1; *x=*x>>1; return tmp; } auto as_StackConcept(int* x){ return StackConcept!(int,bool)(x);} void main() { int stack = 5; pop_second(&stack); writeln(pop(&stack)); writeln(pop(&stack)); }
What about auto pop_second(T)(T* obj) if (__traits(compiles, { T input = T.init; auto stack = input.as_StackConcept(); })) { ... }
Jan 12
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 22:53:39 UTC, jmh530 wrote:
 What about

 auto pop_second(T)(T* obj)
     if (__traits(compiles, {
             T input = T.init;
             auto stack = input.as_StackConcept();
         }))
 {
     ...
 }
Yes, something like that! Except we wrap it up as hasStackConcept!T. So then you can use the constraint "if(hasStackConcept!T)"
Jan 12
prev sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Tuesday, 12 January 2021 at 22:41:03 UTC, Ola Fosheim Grøstad 
wrote:
 On Tuesday, 12 January 2021 at 22:29:09 UTC, Ola Fosheim 
 Grøstad wrote:
 On Tuesday, 12 January 2021 at 22:23:51 UTC, Paul Backus wrote:
 You have written a generic function that accepts any type 
 (unconstrained `T`), but fails to instantiate for most of 
 them (e.g. `pop_second!int` would not compile). In a language 
 like Rust or Java with type-checked generics, the compiler 
 would reject this function definition.
Hm? pop_second requires StackConcept!(T,E) ?
Works fine for me: [...]
The goal is to make it produce a compile-time error given only the *definition* of `pop_second`--so, no main function, no unit tests, and no other usage code. This is impossible to do in D (or C++) if `pop_second` is a template, because D (like C++) does not type-check uninstantiated templates.
Jan 12
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 23:10:30 UTC, Paul Backus wrote:
 The goal is to make it produce a compile-time error given only 
 the *definition* of `pop_second`--so, no main function, no unit 
 tests, and no other usage code.
That's a bit pedantic. And it can never work because of static foreach.
Jan 12
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 23:27:22 UTC, Ola Fosheim Grøstad 
wrote:
 That's a bit pedantic. And it can never work because of static 
 foreach.
Well, I guess it could work, but it would be very challenging when you combine static foreach, static if, string mixins and recursive templates. At some point you end up with an automatic theorem prover.
Jan 12
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 22:23:51 UTC, Paul Backus wrote:
 (e.g. `pop_second!int` would not compile). In a language like 
 Rust or Java with type-checked generics, the compiler would 
 reject this function definition.
Maybe you want it to just bypass it to allow overloading? Then you just test for the presence of as_StackConcept as a constraint in the signature?
Jan 12
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 17:32:17 UTC, Paul Backus wrote:
 As far as I'm aware, C++ does not prevent you from writing code 
 like this:

 template<typename T>
 concept MyConcept = requires (T t) { T.foo(); };

 template<MyConcept T>
 void fun(T t) { t.bar(); }

 In Java or Rust, the above would be a compile-time error.
Btw, when I really want stuff like this in C++ I create a class with a reference to the original class. So then the interface is a wrapper-class and you gain access to it through an overloaded function with a "agreed upon name". E.g. someobject.protected_access.doit() where "protected_access" is an overloaded function that returns a struct with a reference to someobject and the doit() interface.
Jan 12
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 17:53:26 UTC, Ola Fosheim Grøstad 
wrote:
 someobject.protected_access.doit()
In C++ it would obviously be: protected_access(someobject).doit() :)
Jan 12
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 11 January 2021 at 18:23:20 UTC, Q. Schroll wrote:
 [snip]
I recommend you check out Atila's Github profile. I think that he wrote something to address the shortcomings of D template constraints. Also considering your way to think about design, I think there's a good chance you're going to like Tardy and/or Mirror. Keep in mind though that as Mirror isn't yet officially announced, Atila probably does not consider it quite production-ready yet.
Jan 12
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Tuesday, 12 January 2021 at 12:25:31 UTC, Dukc wrote:
 On Monday, 11 January 2021 at 18:23:20 UTC, Q. Schroll wrote:
 [snip]
I recommend you check out Atila's Github profile. I think that he wrote something to address the shortcomings of D template constraints. Also considering your way to think about design, I think there's a good chance you're going to like Tardy and/or Mirror. Keep in mind though that as Mirror isn't yet officially announced, Atila probably does not consider it quite production-ready yet.
Generics is a pure type system feature and no library can emulate it perfectly. As mentioned in my other post, by using D meta programming to implement things like Tardy, even in the best case we still can end up with different instances of functions, sometimes containing the same machine code, just because of a difference between template arguments. Yes, linkers can sometimes remove identical code, but why pay the frontend + backend compilation time cost?
Jan 12
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 13:25:36 UTC, Petar Kirov 
[ZombineDev] wrote:
 Generics is a pure type system feature and no library can 
 emulate it perfectly.
The term "generics" just means parametric types. I think you guys
Jan 12
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 12 January 2021 at 13:36:09 UTC, Ola Fosheim Grøstad 
wrote:
 I think you guys have something more specific in mind based on 

Yeah, in the D context since we obviously have generic templates, I'd take it to mean the Java style. A Java generic doesn't generate new code for other types at all. It is just a runtime class that works in terms of interfaces, and when the compiler parameterizes it, it basically just inserts static casts at the interface boundary for you. The benefit of this is you have almost zero compile time cost and runtime cost comparable to any other class. It avoids template bloat in codegen that can be very significant in D. I'd love to have it as an option in D as well. There's a lot of types that can use identical runtime code and just change types. Not just classes, but like integer types too can be identical and merged, const/immutable/shared/etc can be identical and merged, and even other things with cast(void*) can do it. Lots of potential for use inside druntime itself, changing the existing void* + TypeInfo pairs into templates can mean no more annoying typeinfo requirement... but then it causes runtime bloat. So we probably actually do want to merge, and Java-style generics are a very good way to do it. We could like, just for example _d_arrayappend(ref T[] arr, E ele) forward back to the same implementation functions with pointers, static if branching on special requirements like postblit, just passing the exact parameters it needs to make it work instead of typeinfo... but then having no additional codegen, no additional symbols, no additional indirection, by using the generics. Doing this in today's D comes close with inlined templates but it is still far more expensive than it has to be and really annoying to try to describe. A sum type definition in the template that actually merges would surely help.
Jan 12
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 12 January 2021 at 14:45:36 UTC, Adam D. Ruppe wrote:
 [snip]

 Yeah, in the D context since we obviously have generic 
 templates, I'd take it to mean the Java style.

 A Java generic doesn't generate new code for other types at 
 all. It is just a runtime class that works in terms of 
 interfaces, and when the compiler parameterizes it, it 
 basically just inserts static casts at the interface boundary 
 for you.

 The benefit of this is you have almost zero compile time cost 
 and runtime cost comparable to any other class. It avoids 
 template bloat in codegen that can be very significant in D.

 I'd love to have it as an option in D as well. There's a lot of 
 types that can use identical runtime code and just change 
 types. Not just classes, but like integer types too can be 
 identical and merged, const/immutable/shared/etc can be 
 identical and merged, and even other things with cast(void*) 
 can do it.
 [snip]
Not just classes? Could you explain a bit more about what you are thinking in that paragraph? If it's not a class, then are you talking about a struct? As in something like below. Does the same approach work when it's not a class? generic Number(T) if (isNumber!T) { struct Number { T x; } }
Jan 12
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 12 January 2021 at 14:45:36 UTC, Adam D. Ruppe wrote:
 The benefit of this is you have almost zero compile time cost 
 and runtime cost comparable to any other class. It avoids 
 template bloat in codegen that can be very significant in D.
I haven't looked very closely at Phobos, but it seems like it is a bit compile time heavy ("over complicated") compared to what is most useful ("most common usage"). Perhaps simpler library type semantics with less compile time load would help. Regarding code gen, I thought LDC cached code gen and would avoid emitting the same code twice? If that does not work, then maybe one can bring the IR to a normal form such that more code will be recognized as equivalent?
 I'd love to have it as an option in D as well. There's a lot of 
 types that can use identical runtime code and just change 
 types. Not just classes, but like integer types too can be 
 identical and merged, const/immutable/shared/etc can be 
 identical and merged, and even other things with cast(void*) 
 can do it.
But we probably could fix this by designing libraries with reinterpret casting through (void*) if desired. The template itself does not generate any code. I imagine we could sketch up an alternative std lib based on the most commonly used semantics that Phobos provides. It should of course work alongside Phobos so that people can transition/choose. It does not sound like we need Java-style generics, to me, but I could be wrong. Maybe your own lib could be a starting point for such an effort?
 Lots of potential for use inside druntime itself, changing the 
 existing void* + TypeInfo pairs into templates can mean no more 
 annoying typeinfo requirement... but then it causes runtime 
 bloat.
Ideally the runtime should not contain anything that not every D program uses... Maybe some kind of auto-import would make it possible to slim down the runtime to basically nothing. Basically some kind of feature that lets certain syntax trigger an import in application code (but not in library code). You could config this for the project in a config file and basically choose e.g. what kind of string interpolation semantics you want for you application.
 Doing this in today's D comes close with inlined templates but 
 it is still far more expensive than it has to be and really 
 annoying to try to describe. A sum type definition in the 
 template that actually merges would surely help.
Not exactly sure what you meant by merging here? But if D is going to continue being GC based then a discriminating union type is needed, so that is an area that requires some rethinking (sum types, unions). (I think the only thing that prevents fully precise collection is unions with traced pointers? And precise collection is needed for reliable GC based destruction/finalization.)
Jan 12
prev sibling next sibling parent reply Elronnd <elronnd elronnd.net> writes:
On Tuesday, 12 January 2021 at 14:45:36 UTC, Adam D. Ruppe wrote:
 A Java generic doesn't generate new code for other types at 
 all. It is just a runtime class that works in terms of 
 interfaces, and when the compiler parameterizes it, it 
 basically just inserts static casts at the interface boundary 
 for you.

 The benefit of this is you have almost zero compile time cost 
 and runtime cost comparable to any other class. It avoids 
 template bloat in codegen that can be very significant in D.

 I'd love to have it as an option in D as well. There's a lot of 
 types that can use identical runtime code and just change 
 types. Not just classes, but like integer types too can be 
 identical and merged, const/immutable/shared/etc can be 
 identical and merged, and even other things with cast(void*) 
 can do it.
There was a recent paper about doing this kind of transformation automatically as an optimization - https://www.microsoft.com/en-us/research/uploads/prod/2020/03/kacc.pdf
Jan 13
next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Wednesday, 13 January 2021 at 08:19:25 UTC, Elronnd wrote:
 There was a recent paper about doing this kind of 
 transformation automatically as an optimization - 
 https://www.microsoft.com/en-us/research/uploads/prod/2020/03/kacc.pdf
Thanks for the link. The paper looks like a major advance, one that should strongly influence future compiler architectures.
Jan 13
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 13 January 2021 at 08:19:25 UTC, Elronnd wrote:
 On Tuesday, 12 January 2021 at 14:45:36 UTC, Adam D. Ruppe 
 wrote:
 [...]
There was a recent paper about doing this kind of transformation automatically as an optimization - https://www.microsoft.com/en-us/research/uploads/prod/2020/03/kacc.pdf
Nice paper đŸ“„ (Well, the contents of the paper. Which is not actual paper.. *IQ increases*)
Jan 13
prev sibling parent reply Guillaume Piolat <first.last gmail.com> writes:
On Tuesday, 12 January 2021 at 14:45:36 UTC, Adam D. Ruppe wrote:
 The benefit of this is you have almost zero compile time cost 
 and runtime cost comparable to any other class. It avoids 
 template bloat in codegen that can be very significant in D.

 I'd love to have it as an option in D as well. There's a lot of 
 types that can use identical runtime code and just change 
 types. Not just classes, but like integer types too can be 
 identical and merged, const/immutable/shared/etc can be 
 identical and merged, and even other things with cast(void*) 
 can do it.
A practice I've heard from game industry people was to instantiate template with void* to avoid duplicate template instantiation, and then cast at boundaries. Typically for containers.
Jan 13
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 13 January 2021 at 08:33:58 UTC, Guillaume Piolat 
wrote:
 A practice I've heard from game industry people was to 
 instantiate template with void* to avoid duplicate template 
 instantiation, and then cast at boundaries. Typically for 
 containers.
Yes, that is what I suggested also. I implemented it yesterday for deque, stack, etc, all using the same memory layout for 64 bit values (pointers, ints, doubles etc). What makes it cool is that you can construct datastructures that use the same ranges code, despite having different types. However, it cannot be done without very negative effects on precise collection, I think. So it is a bad fit for D, since it is GC based, and precise collection is the future... So, trashed it. (I translated it to C++ instead... :-P)
Jan 15
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Friday, 15 January 2021 at 11:58:13 UTC, Ola Fosheim Grøstad 
wrote:
 On Wednesday, 13 January 2021 at 08:33:58 UTC, Guillaume Piolat 
 wrote:
 [...]
Yes, that is what I suggested also. I implemented it yesterday for deque, stack, etc, all using the same memory layout for 64 bit values (pointers, ints, doubles etc). What makes it cool is that you can construct datastructures that use the same ranges code, despite having different types. However, it cannot be done without very negative effects on precise collection, I think. So it is a bad fit for D, since it is GC based, and precise collection is the future... So, trashed it. (I translated it to C++ instead... :-P)
If it is instantiated T = void* then it would only be safe to use with pointers anyway, thus using T = object would be an option.
Jan 15
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 15 January 2021 at 17:25:59 UTC, Paulo Pinto wrote:
 If it is instantiated T = void* then it would only be safe to 
 use with pointers anyway, thus using T = object would be an 
 option.
That's a minor detail though. Overall, as long at D is based on GC I guess type erasure should be done by the compiler for traceable pointers. Maybe I'll try again for pointer-free libraries. Basically treating sequences of bytes as values. For instance, you don't really need to compare keys as double, int or chars. You might as well compare them as 4 byte, 8 byte etc sequences. So for a B+tree you could use the same implementation for all kinds of key types.
Jan 15
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 15 January 2021 at 17:36:40 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 15 January 2021 at 17:25:59 UTC, Paulo Pinto wrote:
 If it is instantiated T = void* then it would only be safe to 
 use with pointers anyway, thus using T = object would be an 
 option.
That's a minor detail though. Overall, as long at D is based on GC I guess type erasure should be done by the compiler for traceable pointers. Maybe I'll try again for pointer-free libraries. Basically treating sequences of bytes as values. For instance, you don't really need to compare keys as double, int or chars. You might as well compare them as 4 byte, 8 byte etc sequences. So for a B+tree you could use the same implementation for all kinds of key types.
Type erasure can be tricky, even when it is restricted to basic value types of the same size. This shows up when implementing radix sort where one solution is to map to/from whole numbers (NaN semantics being ignored). That said, good luck on your explorations. Meta programming bloat is vulnerable and deserves to be taken down a peg or three.
Jan 15
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 15 January 2021 at 18:11:04 UTC, Bruce Carneal wrote:
 Type erasure can be tricky, even when it is restricted to basic 
 value types of the same size.  This shows up when implementing 
 radix sort where one solution is to map to/from whole numbers 
 (NaN semantics being ignored).
Yes, I think maybe it can work if one cannot retrieve the key. Then one can store it in a coded fashion that sorts correctly as byte sequences?
Jan 15
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Friday, 15 January 2021 at 18:14:22 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 15 January 2021 at 18:11:04 UTC, Bruce Carneal wrote:
 Type erasure can be tricky, even when it is restricted to 
 basic value types of the same size.  This shows up when 
 implementing radix sort where one solution is to map to/from 
 whole numbers (NaN semantics being ignored).
Yes, I think maybe it can work if one cannot retrieve the key. Then one can store it in a coded fashion that sorts correctly as byte sequences?
You can transform to a canonical relop form wherever you'd like, of course, but mapping on entry and unmapping on retrieval or exit from a collection library would, as you might imagine, lower conversion overhead for the second and subsequent relops, reduce bloat, and enable kernel fusion. All of my use cases for this relop type erasure to date have involved fused operations where the overhead of an additional store/load out of an intermediate collection would have been very difficult to swallow. But if you're looking at something less predictable I'm guessing that type erased collections could be a win. If you decide to pursue it, a report on the good, bad and ugly would be appreciated. Good luck.
Jan 15
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 16 January 2021 at 00:03:00 UTC, Bruce Carneal wrote:
 You can transform to a canonical relop form wherever you'd 
 like, of course, but mapping on entry and unmapping on 
 retrieval or exit from a collection library would, as you might 
 imagine, lower conversion overhead for the second and 
 subsequent relops, reduce bloat, and enable kernel fusion.
The problem is little endian. Ascii strings will have to be reversed. The order of two 32 bit ints have to be reversed. These issues are not present for big endian...
Jan 15
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Saturday, 16 January 2021 at 05:39:02 UTC, Ola Fosheim Grostad 
wrote:
 On Saturday, 16 January 2021 at 00:03:00 UTC, Bruce Carneal 
 wrote:
 You can transform to a canonical relop form wherever you'd 
 like, of course, but mapping on entry and unmapping on 
 retrieval or exit from a collection library would, as you 
 might imagine, lower conversion overhead for the second and 
 subsequent relops, reduce bloat, and enable kernel fusion.
The problem is little endian. Ascii strings will have to be reversed. The order of two 32 bit ints have to be reversed. These issues are not present for big endian...
It sounds like mappings to arbitrary precision big endian unsigned is where you're headed currently. Implementing relop-unifying xforms to whatever form you actually choose should not be difficult. You have the types in hand so you're looking at a specialized binary serialization problem. Coming back out again is trickier I think.
Jan 15
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Saturday, 16 January 2021 at 06:33:13 UTC, Bruce Carneal wrote:
 It sounds like mappings to arbitrary precision big endian 
 unsigned is where you're headed currently.
More like converting to ulong snd ucent. But CPUs have instructions for endian conversion so that is ok. Converting from signed to unsigned is just one add.
 Implementing relop-unifying xforms to whatever form you 
 actually choose should not be difficult.  You have the types in 
 hand so you're looking at a specialized binary serialization 
 problem.  Coming back out again is trickier I think.
I think most conversion will only take 1-4 cycles. The advantage is that once everything is uniform you can use handcoded SIMD in the container algorithms, which would be too much work otherwise... Dunno if the trade off is worth it,but it might? Btw, one challenge for getting compiler level type erasure is that function addresses cannot be used for type identity, maybe a language spec issue?
Jan 15
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 16 January 2021 at 06:57:53 UTC, Ola Fosheim Grostad 
wrote:
 On Saturday, 16 January 2021 at 06:33:13 UTC, Bruce Carneal 
 wrote:
 It sounds like mappings to arbitrary precision big endian 
 unsigned is where you're headed currently.
More like converting to ulong snd ucent. But CPUs have instructions for endian conversion so that is ok. Converting from signed to unsigned is just one add.
Or, more precisely, make it architecture dependent. I guess that is the crux. The library has to provide inline-able conversion operations.
Jan 15
prev sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 15 January 2021 at 18:11:04 UTC, Bruce Carneal wrote:
 value types of the same size.  This shows up when implementing 
 radix sort where one solution is to map to/from whole numbers 
 (NaN semantics being ignored).
If we accept the following encoding for floating point then it should work out ok? INPUT OUTPUT s exp sig s exp sig 1 1100 1111110 0 0011 0000001 1 0011 0000001 0 1100 1111110 1 0000 0000000 0 1111 1111111 0 0000 0000000 1 0000 1111111 0 0011 0000011 1 0011 0000001 0 1100 1111110 1 1100 1111110 Algorithm: 1. flip the signbit 2. if the flipped sign is 0 then negate the exponent and signficand/mantissa. And it can be reversed just as easily? Not too bad!?
Jan 16
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 16 January 2021 at 08:41:18 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 15 January 2021 at 18:11:04 UTC, Bruce Carneal wrote:
 value types of the same size.  This shows up when implementing 
 radix sort where one solution is to map to/from whole numbers 
 (NaN semantics being ignored).
If we accept the following encoding for floating point then it should work out ok? INPUT OUTPUT s exp sig s exp sig 1 1100 1111110 0 0011 0000001 1 0011 0000001 0 1100 1111110 1 0000 0000000 0 1111 1111111 0 0000 0000000 1 0000 1111111
Typo: 0 0000 0000000 1 0000 0000000 Maybe I am overlooking something... This is like 1-2 cycles.
Jan 16
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 16 January 2021 at 08:45:23 UTC, Ola Fosheim Grøstad 
wrote:
 Maybe I am overlooking something... This is like 1-2 cycles.
I haven't tested, so I could be in error, but it seems like these two might work? ulong x = floatingpoint double value; 1: x ^ ((0ULL - (x>>63)) | (1ULL<63)) or 2: x & (1ULL<63) ? ~x : x | (1ULL<63) So basically in generic assembly: 1: shift right, sub, or, xor => 4 very fast ops 2: tst, cmp, (neg / or) => 2 fast ops + 1 branch If this works, then there is really no reason not to use ulong/uint for floating point keys, except -0.0 and 0.0 will be sorted, but that is desirable sometimes, so could be a plus as well. If people don't want that then they should normalize to 0.0 before using the key.
Jan 16
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Saturday, 16 January 2021 at 09:28:22 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 16 January 2021 at 08:45:23 UTC, Ola Fosheim 
 Grøstad wrote:
 Maybe I am overlooking something... This is like 1-2 cycles.
I haven't tested, so I could be in error, but it seems like these two might work? ulong x = floatingpoint double value; 1: x ^ ((0ULL - (x>>63)) | (1ULL<63)) or 2: x & (1ULL<63) ? ~x : x | (1ULL<63) So basically in generic assembly: 1: shift right, sub, or, xor => 4 very fast ops 2: tst, cmp, (neg / or) => 2 fast ops + 1 branch If this works, then there is really no reason not to use ulong/uint for floating point keys, except -0.0 and 0.0 will be sorted, but that is desirable sometimes, so could be a plus as well. If people don't want that then they should normalize to 0.0 before using the key.
Here's a link on the topic: http://stereopsis.com/radix.html. Excerpts from that for the 32 bit float case follow: Converting over: uint32 mask = -int32(f >> 31) | 0x80000000; return f ^ mask; and back: uint32 mask = ((f >> 31) - 1) | 0x80000000; return f ^ mask; This form is branchless and is easily (SIMD) vectorized. As you've noted, there are some oddities that arise when using unsigned relops against the mapped values. Negative and positive zeroes are distinct and NaNs take on a definite, and split, ordering. For my current work I prefer this to traditional float behavior and find it a useful bijection overall. YMMV.
Jan 16
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 16 January 2021 at 17:03:41 UTC, Bruce Carneal wrote:
 Converting over:
 	uint32 mask = -int32(f >> 31) | 0x80000000;
 	return f ^ mask;
 and back:
 	uint32 mask = ((f >> 31) - 1) | 0x80000000;
 	return f ^ mask;
Thanks, this is the same I have as option 1 above.
 This form is branchless and is easily (SIMD) vectorized.
Yes, and perhaps also better for the CPU pipeline.
 split, ordering.  For my current work I prefer this to 
 traditional float behavior and find it a useful bijection 
 overall.  YMMV.
Out of curiosity, what do you need to sort floats for?
Jan 16
parent reply Bruce Carneal <bcarneal gmail.com> writes:
On Saturday, 16 January 2021 at 19:43:53 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 16 January 2021 at 17:03:41 UTC, Bruce Carneal 
 wrote:
 Converting over:
 	uint32 mask = -int32(f >> 31) | 0x80000000;
 	return f ^ mask;
 and back:
 	uint32 mask = ((f >> 31) - 1) | 0x80000000;
 	return f ^ mask;
Thanks, this is the same I have as option 1 above.
Almost certainly the same. Only the most aggressively stupid compiler modes would forego an available/advantageous conversion of the subtract to a mono-operand negation. Even then, once any loop got rolling throughput should be identical. Yes.
 This form is branchless and is easily (SIMD) vectorized.
Yes, and perhaps also better for the CPU pipeline.
Unless the data you're dealing with is nearly sorted, the branch mispredict penalty could really hurt so, yeah, don't go there. For the branchless variant, throughput will come down to issue capability. For a dual issue SIMD CPU it looks like a naive loop should hit throughput of 2 SIMD vectors every three cycles (I don't have real numbers for the standalone case, all my transforms appear within larger basic blocks). SIMT throughput should be memory subsystem limited.
 split, ordering.  For my current work I prefer this to 
 traditional float behavior and find it a useful bijection 
 overall.  YMMV.
Out of curiosity, what do you need to sort floats for?
I've been working on my current project for a few months but I'm still not ready to talk about it in detail. I will say that it does not sort anything (doesn't have the power/compute budget for sorting) and that it does employ the bijection as a type erasure/restoration mechanism.
Jan 16
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 17 January 2021 at 04:03:30 UTC, Bruce Carneal wrote:
 I've been working on my current project for a few months but 
 I'm still not ready to talk about it in detail.  I will say 
 that it does not sort anything (doesn't have the power/compute 
 budget for sorting) and that it does employ the bijection as a 
 type erasure/restoration mechanism.
This "bijection" strategy is interesting. (I assume you think of bijective functions in mathematics?) For some reason I've never really given it much thought. But it makes a lot of sense for encoding keys. Some online services also only accept keys that are either strings or 64bit integers, so it might be useful in other contexts. I've written a generic key type that does this encoding (in C++, but easy to port to D), and are working on a compressing one. So, for instance if you have a tuple of (z,y,x) then you can specify that 1≤x≤31, 1≤y≤12, 1970≤z≤2030 and let it be compressed either by bit shifting or multiplication (slower but tighter). So for instance (2021,1,17) would compress as ((2021-1970)*12+0)*31+16 Is there some way to find out the range (min, max) of an enum? The next step is to cover keys larger than 64 bits, I guess I should cover up to 256 bits.
Jan 17
parent Bruce Carneal <bcarneal gmail.com> writes:
On Sunday, 17 January 2021 at 10:37:10 UTC, Ola Fosheim Grøstad 
wrote:
 On Sunday, 17 January 2021 at 04:03:30 UTC, Bruce Carneal wrote:

 This "bijection" strategy is interesting.  (I assume you think 
 of bijective functions in mathematics?)
Yes, one-to-one and onto (and we've wandered quite a ways OT). Good luck.
Jan 17
prev sibling next sibling parent Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Monday, 11 January 2021 at 18:23:20 UTC, Q. Schroll wrote:
 I don't want to be mistaken. I know what the differences of 

 are. Maybe my question has obvious answers and I just don't see 
 them.

 [...]
I agree with everything you said. Even though I greatly enjoy fully-erased typing. Type-checking has been described as the most successful form of light-weight formal verification and some of my TypeScript usage feels like this (compared to using pure JavaScript). Sometimes I don't need **or want** different code to be generated depending on the generic parameters, I just want the type system semantics and the light-weight formal verification (e.g. implementing units of measure).
Jan 12
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
Go now has a generics proposal:

https://github.com/golang/go/issues/43651
Jan 13
prev sibling parent sighoya <sighoya gmail.com> writes:
On Monday, 11 January 2021 at 18:23:20 UTC, Q. Schroll wrote:
 The only programming language I know of that has both, 
 templates and generics, is C++/CLI and ones closely related.


 not have generics.
Because OOP could be rarely supported in D without OOP and pure template programming while templates already serve the need for generics excluding the complexity they are introducing.
 A generic class or interface states its requirements (base 
 classes, interfaces, [never seen in the wild:] subclasses, ...) 
 to its type parameters exactly.
D can already do that with where constraints.
 Everything that is part of the implementation is checked when 
 the generic aggregate is defined.
So simply speaking you seek for eagerly checked templates which indeed seems to be an advantage of generics but why not optionally the same for templates? Rather reinventing the wheel, why not modulating the template error system to infer and uppropagate where constraints automatically by traversing type/function bodies? Another issue of generics are the parametrized error messages often disliked by people using them. We could do that, in theory, better just by mentioning the position of the occurred error in the template-expanded code fragment similar to how Python handles type errors. It would remove the barrier of template utilization a lot.
 Generics allow for implicit conversion by covariance and 

 interface to its covariant or contravariant part-interface 
 (that is a supertype of the interface, really). (Java [2, 3])
I don't see any reason why not providing them with templates, too with specialized syntax for example by: //Covariance dlist!(T where T:A || T:B) ==> dlist!(Algebraic!(A,B)) //Contravariance dlist!(T where A:T) ==> dlist!(Object)//where compiler rejects any assignment of A's strict subtypes.
 Using templates, the compiler checks requirements only for 
 specific instances. It might be that the requirements are 
 insufficient, but because no test tried the potentially very 
 specific type argument, it will be unrecognized.
Yep, sorta implicit where constraints would serve the purpose here.
 Also, one feature D doesn't have, is expressing the precise 
 union or intersection of interfaces: Say you have two 
 interfaces I and J.
Isn't a question about templates rather about intersection and union types as language level concept or as library solution.
 The interface (I & J) has all the methods specified by any of 
 them. A class that implements I and J automatically implements 
 (I & J).
 The interface (I | J) has all the methods specified by both of 
 them. A class that implements I or implements J automatically 
 implements (I | J). If you e.g. iterate an (I | J)[] object, 
 you can call any method required by both interfaces. 
 (Typescript [4])
 It might be hard or even impossible to implement this using 
 vtables and stuff.
Personally, I think it can with kinda implicitCoercionOp and Algebraic and some Intersection like variant.
 In D, one can easily create templates intersectInterface(Is...) 
 and unionInterface(Is...) that basically do that.

 It could very well be that D doesn't have them because they 
 have to be implemented and maintained, and the cost/benefit 
 ratio wasn't good enough.
D has already Algebraic for Unions, don't know about Intersection implementations. Note that the implementation for Unions vary. In Scala (and union of two classes is internally just the supertype of both classes and the intersection of interfaces are classes/interfaces implementing/extending all the said interfaces which could implemented with some support of compile time reflection for OOP hierarchies. It has however the disadvantage of overloading ambiguities when two pairs of classes have the same supertype. But I would prefer to support other types than classes and interfaces as well just as it is the case with Algebraic.
Jan 13