Re: [boost] Tuple library accepted

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-06-30 01:08:52

On Saturday 30 June 2001 12:26, you wrote:
> Peter Dimov wrote:
> > > This gets rid of the compile time overhead completely,
> > > allows a reasonable limit on the size of tuples,
> > > allows important optimisations, and may be mandatory
> > > for generalising certain other library components
> > > efficiently.
> >
> > This would probably be a step in the right direction, but the more
> > important issue is how do you get from the function call expression
> >
> > f(x, y, z, 5)
> >
> > a tuple containing the arguments.
> >
> > Writing 10,000 operator()'s doesn't feel right. :-)
>
> 	Step 1: you ban operator, [comma], either
>
> 		a) completely (prefered)
> 		b) inside brackets
>
> 	Step 2: you define , as tuple constructor:
>
> 	x,y,z  -- a triple
> OR
>
> 	(x,y,z) -- if you only banned , inside brackets
>
> Now:
>
> 	f (x,y,z)
>
> is precisely
>
> 	f (t)
>
> where t == (x,y,z)
>
> See Felix. This is exactly what I do. It is also exactly
> what SML does.
>
> Note: there is no tuple with one element!

One need only lift the restriction that operator, cannot be overloaded for 
primitive datatypes to give tuples a more natural construction interface. 
Tuples may be an exception because they are so basic, but I would say that 
the first question one should ask when implementing a new language feature is 
'what prevents this from being part of a library instead of the language?'

        Doug