static arrays becoming value types

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Oct 21 08:48:34 PDT 2009


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



More information about the Digitalmars-d mailing list