On Wed, Oct 21, 2009 at 8:48 AM, Andrei Alexandrescu <[email protected]> wrote: > 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?
Well, auto-flattening is a colossally bad idea to be sure. --bb
