--- Ian McCulloch wrote:
> It is a month early, but I have a proposal for the amusement of the
> community.

A month early for what? I assume something in the C++ standardization
process. If so, how does one find out about such things without asking
on here?

-- Matt

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Matt Bitten wrote:
> --- Ian McCulloch wrote:
>> It is a month early, but I have a proposal for the amusement of the
>> community.
>
> A month early for what? I assume something in the C++ standardization
> process. If so, how does one find out about such things without asking
> on here?

A month early for April 1. See, e.g.,
http://www.research.att.com/~bs/whitespace98.pdf

Jonathan


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Matt Bitten wrote:

> --- Ian McCulloch wrote:
>> It is a month early, but I have a proposal for the amusement of the
>> community.
>
> A month early for what? I assume something in the C++ standardization
> process. If so, how does one find out about such things without asking
> on here?

Yes, April 1st is a very popular time for proposing new features for C++.
See for example http://www.research.att.com/~bs/whitespace98.pdf

Cheers,
Ian

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

ianmcc@physik.rwth-aachen.de (Ian McCulloch) writes:

> Matt Bitten wrote:
>
>> --- Ian McCulloch wrote:
>>> It is a month early, but I have a proposal for the amusement of the
>>> community.
>>
>> A month early for what? I assume something in the C++ standardization
>> process. If so, how does one find out about such things without asking
>> on here?
>
> Yes, April 1st is a very popular time for proposing new features for C++.
> See for example http://www.research.att.com/~bs/whitespace98.pdf

Well, you suckered me, I have to admit.  That said, there's something
really interesting about your approach to typeof and decltype.
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams wrote:

> ianmcc@physik.rwth-aachen.de (Ian McCulloch) writes:
>
>> Matt Bitten wrote:
>>
>>> --- Ian McCulloch wrote:
>>>> It is a month early, but I have a proposal for the amusement of the
>>>> community.
>>>
>>> A month early for what? I assume something in the C++ standardization
>>> process. If so, how does one find out about such things without asking
>>> on here?
>>
>> Yes, April 1st is a very popular time for proposing new features for C++.
>> See for example http://www.research.att.com/~bs/whitespace98.pdf
>
> Well, you suckered me, I have to admit.  That said, there's something
> really interesting about your approach to typeof and decltype.

No no, it was a completely serious proposal.  I hope something like it gets
into the language, although it looks like there are some tricky issues to
solve.

I just added that bit since it happened to be 1st March when I submitted
it ;)

Cheers,
Ian

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nobody@example.com (Ian McCulloch) writes:

> David Abrahams wrote:
>
>> ianmcc@physik.rwth-aachen.de (Ian McCulloch) writes:
>>
>>> Matt Bitten wrote:
>>>
>>>> --- Ian McCulloch wrote:
>>>>> It is a month early, but I have a proposal for the amusement of
>>>>> the community.
>>>>
>>>> A month early for what? I assume something in the C++
>>>> standardization process. If so, how does one find out about such
>>>> things without asking on here?
>>>
>>> Yes, April 1st is a very popular time for proposing new features
>>> for C++.  See for example
>>> http://www.research.att.com/~bs/whitespace98.pdf
>>
>> Well, you suckered me, I have to admit.  That said, there's
>> something really interesting about your approach to typeof and
>> decltype.
>
> No no, it was a completely serious proposal.  I hope something like
> it gets into the language, although it looks like there are some
> tricky issues to solve.

Planning to write a proposal?  There's not much chance it will even
come up for discussion otherwise.

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi,

It is a month early, but I have a proposal for the amusement of the
community.

Let T be a template, and x1, x2, ..., xn be types.  Then define

T(x1, x2, ..., xn) [note round brackets]

to be an alias for
typename T<x1, x2, ..., xn>::type

If there is no such nested type, then the expression is ill-formed.

In addition, if any (or all) of the xi are expressions, then the effect is
that of substituting decltype(xi).  This opens up the possibility of
ambiguity between the type-valued function and a constructor call; exactly
how to resolve that is not specified here.

With this language extension, it would be possible to define decltype and
typeof within the language, ie

template <typename T>
struct decltype
{
   typedef T type;
};

template <typename T>
struct typeof : boost::remove_const<
   typename boost::remove_reference<T>::type
> {};  // or whatever typeof is supposed to be ;-)

Extending this idea to allow integral constants as well as types for the
nested ::type member, this would allow sizeof-like functions to be defined
(eg, length(array_type), alignment_of, etc), limited only by what can be
defined via a metafunction.

Is this idea completely silly?

Cheers,
Ian



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

nobody@example.com (Ian McCulloch) writes:

> Hi,
>
> It is a month early, but I have a proposal for the amusement of the
> community.
>
> Let T be a template, and x1, x2, ..., xn be types.  Then define
>
> T(x1, x2, ..., xn) [note round brackets]
>
> to be an alias for
> typename T<x1, x2, ..., xn>::type
>
> If there is no such nested type, then the expression is ill-formed.
>
> In addition, if any (or all) of the xi are expressions, then the effect is
> that of substituting decltype(xi).  This opens up the possibility of
> ambiguity between the type-valued function and a constructor call; exactly
> how to resolve that is not specified here.

Of course, there's also the detail that some templates accept
arguments that can be expressions:

  template <int X> struct foo;
  foo(3 + 5)
>
> With this language extension, it would be possible to define decltype and
> typeof within the language, ie
>
> template <typename T>
> struct decltype
> {
>    typedef T type;
> };
>
> template <typename T>
> struct typeof : boost::remove_const<
>    typename boost::remove_reference<T>::type
>> {};  // or whatever typeof is supposed to be ;-)

!!!

Well, that's astounding.  It's always nifty to be able to move
would-be language extensions into the library space by generalizing.

> Extending this idea to allow integral constants as well as types for the
> nested ::type member, this would allow sizeof-like functions to be defined
> (eg, length(array_type), alignment_of, etc), limited only by what can be
> defined via a metafunction.
>
> Is this idea completely silly?

Nope. I'm not sure we need a language extension to get the nice
syntax, though!

http://aspn.activestate.com/ASPN/Mail/Message/boost/1438788

Yes, Aleksey is some kind of crazy Siberian computer god.  I wonder if
these ideas can be combined somehow?

Cheers,
--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

David Abrahams wrote:
> nobody@example.com (Ian McCulloch) writes:
>
> > Hi,
> >
> > It is a month early, but I have a proposal for the amusement of the
> > community.
> >
> > Let T be a template, and x1, x2, ..., xn be types.  Then define
> >
> > T(x1, x2, ..., xn) [note round brackets]
> >
> > to be an alias for
> > typename T<x1, x2, ..., xn>::type
> >
> > If there is no such nested type, then the expression is ill-formed.
> >
> > In addition, if any (or all) of the xi are expressions, then the
effect is
> > that of substituting decltype(xi).  This opens up the possibility
of
> > ambiguity between the type-valued function and a constructor call;
exactly
> > how to resolve that is not specified here.
>
> Of course, there's also the detail that some templates accept
> arguments that can be expressions:
>
>   template <int X> struct foo;
>   foo(3 + 5)

True. However, since this transformation is limited to class templates,
we only have one definition of X. Even with partial specializations we
know which argument is type, and which is non-type.

So, for an automated parser there's no problem. Of course, the most
common form of parser is still the human parser ;) so perhaps we ought
to change the ( ) to { }. There's no reason we can't have decltype{5+3}
and it may be slightly easier for a lot of parsers. For consistency, we
might add sizeof{ } as well. That's already Core, they don't have to do
all the fancy footwork like MPL.

> > Extending this idea to allow integral constants as well as types
for the
> > nested ::type member, this would allow sizeof-like functions to be
defined
> > (eg, length(array_type), alignment_of, etc), limited only by what
can be
> > defined via a metafunction.

In which case we'd better name the member result. I remember
discussions
in Core about the problems in name mangling due to complex template
constructions in declarations. I can imagine that such a generalized
construct causes even more problems, to the point where it cannot be
used in function declarations anymore. That would be a shame, it
would seriously undermine the value of decltype.

Regards,
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]