language_fan wrote:
Wed, 21 Oct 2009 11:07:29 -0400, Robert Jacques thusly wrote:
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'm late in this dialog, but I'm not seeing an impediment here. What
does it matter to you that tuples actually have a name vs. not having a
name at all?
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.
How and why are they treated badly?
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.
What exactly didn't D's tuples get right?
Andrei
