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
> (x,y,z) -- if you only banned , inside brackets
> 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?'
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk