Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote: > On Wed, 21 Oct 2009 02:23:09 -0400, language_fan <f...@bar.com.invalid> > wrote: >> Tue, 20 Oct 2009 16:25:05 -0400, Robert Jacques thusly wrote: >> >>> On Tue, 20 Oct 2009 15:19:15 -0400, language_fan <f...@bar.com.invalid> >>> wrote: >>> >>>> Real tuple types do not have a special type tag which gets injected >>>> implicitly with structs. So every time you try to do something >>>> lightweight by emulating tuples, you need to refer to the global >>>> Tuple type or bang your head to the wall. >>> >>> Or use a templated opAssign mixin to allow two desperate types to be >>> assigned to each other. >> >> Wow, you need templates to implement == for built-in values types, >> nice.. > > Unlike C++, D templates don't require a PhD to use. And it's definitely > better that banging your head against the wall. > >>> Besides, I think you're comparing apples to oranges. In the SOL >>> example, you use the same declaration for all types. Shouldn't the SOL >>> example be: >>> >>> val a = (1,2) : [Int,Int] >>> val b = (1,2) : [Int,Int] >>> val c = (2,3) : MyCustomTupleType[Int,Int] >>> >>> which would probably generate: >>> assert(a == b); // ok >>> assert(a != c); // Error: incompatible types for ((a) != (b)) >> >> If you have built-in tuple literals, there is no way you can build a >> MyCustomTupleType without resorting to other language features. There >> are no apples and oranges, cause they both are seen as (Int,Int) by the >> equivalence checker. Do you understand how equivalence works in >> structural typing system (http://en.wikipedia.org/wiki/ >> Structural_type_system) vs nominal typing? In structural equivalence >> there are no names attached to the types (well there might be, but >> those are omitted in the comparison), only their internal structure >> matters. >> >> Why would anyone want to create two incompatible tuples by default as >> you still would have 'typedef' and 'struct' for implementing just that. > > My issue was that all your example _showed_ was nominal typing. Though I > didn't mention it by name, I did mention that if SOL tuples had > structural typing, it might would be a different story. (Well, until/if > opImplicitCast was implemented, as it would allow for structural > typing.)
Why do you insist on using nominal typing for tuples and the library defined "literal". If I want plain old tuples without any kind of type name, why should I care about extra hand waving needed to make it work. I see opImplicitCast, introspection done with templates and all kinds of other voodoo to be ugly hacks. This is nothing more than one of the basic value types without any special semantics, for $deity's sake. If you like the hacky approach so much, why don't all built-in types (like static arrays etc.) use the same method? Implementation wise tuples are much simpler than D's arrays or AAs, still they are treated like some 2nd class citizen from some notorious 3rd world country. Why is it so damn hard to change the 90% correctly implemented built-in tuples to work like in any other tuple supporting language. Do you somehow fancy verbose syntax for C++ compatibility reasons (ah, the good old std::tr1::make_tuple<int, int>, makes me want to wank every time..) Try Ruby, try python, try *ML etc. They all somehow got it right.
