Jesse Phillips Wrote:
> Morlan Wrote:
>
> > While trying to understand the expand mechanism presented in the TDPL book I
> > tried to read std.typetuple and std.typecons files. I found a true nightmare
> > in those files in the form of an almost infinite chain of aliases and macro
> > processing. How can one understand a written text if the words are redifined
> > in every other line? And people say that goto instruction is bad? Please
> > give
> > me a break.
>
> The aliases serve to simplify things. You would find it even more
> overwhelming if the true types were used. Aliases should show their base type
> in the documentation though.
>
> > Anyway, at some point I realized that I cannot understand what is going on
> > because there is some language mechanism in action which I do not know. I
> > wrote a small program to confirm this. Here it is:
> >
> > struct S { TypeTuple!(int, double) field; }
> > void main(){
> > S mys;
> > mys.field[0] = 4;
> > mys.field[1] = 4.4;
> > }
> >
> > It compiles all right. But if you replace the S's definition with {int,
> > double
> > field;}
> > it does not compile. So tuples are clearly much more than a sequence of
> > types
> > and they trigger a completely different semantic action than a plain
> > sequence
> > of types. Is there a precise definition of tuples somewhere?
>
> struct S { int, double field; }
>
> Right, tuples have very little syntactic sugar. And frankly this wouldn't be
> the syntax I would want.
>
> I don't think there is any good introduction to D tuples. The best way to
> think of them is to know they are compile time constructs. They are their
> purely to be manipulated during compilation and have no meaning at runtime.
> These types are made possible because of language features like templates,
> mixins, and alias parameters.
>
> Another issue is that D isn't very strict. We have TypeTuple and Tuple, both
> of which can contain types and values. But it doesn't look like things will
> be changing.
Fuck no! "precise definition of tuples" is something that always makes me
really grumpy. Do we want a incomprehensible ivory tower language or something
practical? The D's tuples are a bit hazy. A bit harder to grok, but the good
sides are better performance, flexibility and friendliness towards pragmatic
c/c++ mentality. If you want something "better", go use Haskell an enjoy your
90% slower runtimes.
People always complain about missing documentation, but I don't care. Better
developers don't need documentation, they value the tools. Walter spends 95%
time on developing tools, 5% helping the community in this newsgroup and in
conferences.
