Robert Jacques, el 20 de octubre a las 21:06 me escribiste: > >>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. > > > >Yes, D support for tuples is way far from ideal. > > How so? I think this is merely the difference between a library type > in a flexible language and a built-in type in an inflexible > language. I mean the example was essentially: > In D: > Apple a > Apple b > Orange c > > assert(a != c); // Error: incompatible types Apple and Orange > > In SOL: > Apple a > Apple b > Apple c > > assert(a != c); // ok, both a and c are apples.
I wasn't referring to this particular example, even when I agree this is not a big issue, is much more difficult to end up comparing Apples to Oranges if the language have support for tuple literals (like in the example). In D I think you might find yourself in this situation more often, but still rarely. I think tuple literals is an important thing to encourage people using tuples, specially when you want to support functional programming style. > Now, if SOL allowed tuples to do things you can't do today in D, > like assign a tuple to a struct with the same signature, then this > might be a point. But that wasn't the example given. Yes, that's another thing that can be done without real tuple support in the language. Anyway, I guess I was a little exaggerated with '*way far* from ideal', but I'm convinced there is plenty of room for improvements. =) -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ ---------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------- FINALMENTE EL CABALLITO FABIAN VA A PASAR UNA BUENA NAVIDAD -- Crónica TV
