"Terje Sletteb?" <tslettebo@hotmail.com> wrote in message
news:b0491891.0407120247.e6a70d8@posting.google.com...
>
> Besides, how many uses "auto" nowadays...? After all, it's an optional
> keyword. Even if it's used somewhere, a compiler might warn if the
> deduced type isn't used elsewhere (as in the case of the typo).

Alas, this proposal competes from the use of the "auto" keyword
with another proposal whose purpose is to disambiguate certain
declarations that use function-lookalike default constructor syntax:

T x();   // Declares a function returning an object of type 'T'
auto T x();  // Declares a default-constructed instance of 'T'

Clearly both cannot be implemented by the same language, and so
preferring one proposal over the other becomes an issue.

 - Risto -

---
[ 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                       ]

gdr@cs.tamu.edu (Gabriel Dos Reis) wrote (abridged):
>    for (auto p = v.begin(); p != v.end(); ++p)

Just to be clear, I wasn't objecting to that syntax, or indeed anything in
N1607. I was concerned about Terje Sletteb's suggestion that the deduced
type be given a new name in the same declaration. The equivalent of:

    for (auto iterator p = v.begin(); p != v.end(); ++p)

which gives meaning to both "p" and "iterator". The above is already valid
syntax, so Terje's suggestion would either change its meaning, or else
make it depend on whether the name "iterator" was already in scope.

Although being able to write:

    for (auto iterator p = v.begin(); p != v.end(); ++p) {
        iterator q = p + 1;
    }

might be nice, I suspect I'd be as happy to just use auto again:

    for (auto p = v.begin(); p != v.end(); ++p) {
        auto q = p + 1;
    }

Admittedly this might give q a different type to p, but it probably
doesn't, and if it does it probably doesn't matter, and if it does matter
then I'd be content to use a more verbose expression to nail it.

-- Dave Harris, Nottingham, UK

---
[ 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                       ]

Terje Sletteb? wrote:
> Hi all.
>
> In proposal N1607 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf),
> there's a proposal for two new keywords (or reuse of one, for another
> purpose, and a new keyword): "decltype" and "auto".


    On the "auto" front:

    "let" has also been proposed for that purpose.  "let" is clearer.
but introduces a new keyword.  A problem with "auto" is that
is already an attribute, and valid in the same place as a type.

    Do you write

 static auto i = x;

    or

 auto static i = x;

    Is it legal to write

 auto auto i = x;

The proposed solution in the paper is to remove "auto" as
a storage class specifier, which breaks backwards compatibility.

    Also, allowing

 foo<auto>

    and

 new auto(1)

    seems unnecessarily complicated.  Within templates,
"typeof" solves most of those problems.

    The one common idiom for which "let" is really needed
is

 for (let p = tab.begin(); p != tab.end(); p++)

because the "typeof" form

 for (typeof(tab.begin())::iterator p = tab.begin();
  p != tab.end(); p++)

is so bulky.  (Is that even legal?)

One alternative would be to allow

 for (iterator<tab> p = tab.begin(); p != tab.end(); p++)

That's simple and understandable.


     John Nagle
     Animats


---
[ 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                       ]

AlbertoBarbati@libero.it (Alberto Barbati) writes:

> David Abrahams wrote:
>> brangdon@cix.co.uk (Dave Harris) writes:
>>>
>>>    typedef decltype( f() ) type_name;
>>>    type_name a1 = f();
>>>    type_name a2 = g();
>> Yes.  Repeated code is a maintenance and expressivity problem.  That
>> idiom forces you to repeat the expression f().  The expression is
>> short in this case, but could sometimes be much more complicated.
>>
>
> You can avoid duplicating the expression f() by writing:
>
>    auto a1 = f();
>    decltype(a1) a2 = g();

Uh, thanks.  I posted because Dave Harris was asking if it's really
important to be able to use auto in this way.  I was explaining why
it is important.

--
Dave Abrahams
Boost Consulting
http://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                       ]

tslettebo@hotmail.com (Terje Sletteb?) writes:

| Besides, how many uses "auto" nowadays...? After all, it's an optional
| keyword.

It is essentially meaningless.  The proposal is giving a keyword with
pratically no meaning.

   for (auto p = v.begin(); p != v.end(); ++p)

the initialization part reads

    "automa[gt]ically ascribe the deduced expression type to the
     variable p"

This looks good to me.  It may worth pointing that "auto" had been
implemented in earlier experimental versions of CFront (circa 1982,
1983) with exactly this semantics.  It is kind of ironic that we have
to wait more than two decades before discussing it again.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

nagle@animats.com (John Nagle) writes:

| Terje Sletteb? wrote:
| > Hi all.
| > In proposal N1607
| > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf),
| > there's a proposal for two new keywords (or reuse of one, for another
| > purpose, and a new keyword): "decltype" and "auto".
|
|
|     On the "auto" front:
|
|     "let" has also been proposed for that purpose.  "let" is clearer.
| but introduces a new keyword.  A problem with "auto" is that
| is already an attribute, and valid in the same place as a type.

Yes, an attribute with essentially no meaning.

I've had an experimental implementation of decltype and auto proposal
in my GCC cxx-reflection-branch more than a year ago (and I've been
having fruitful conversations with Peter Dimov who tried it on the the
TR bind proposal).  Unfortunately, some unplanned succession of events
led me unwillingly screw up the branch :-(  I'll try to restore it in
usable state once I got some spare time [24 hours in a day is not
enough]. But, the point that it is not difficult to implement -- you
just need to remember that "auto" was used as a decl-specifier (and
you have to do it anyway) and synthetize a "type variable" for which
you find a value through the already existing template argument
deduction machinery.

|     Do you write
|
|  static auto i = x;
|
|     or
|
|  auto static i = x;

Is it any different from

      int static i = x;

?

Don't forget that class storage specifiers are declaration specifiers,
so they can appear in any order with other decl-specifiers.

|     Is it legal to write
|
|  auto auto i = x;
|
| The proposed solution in the paper is to remove "auto" as
| a storage class specifier, which breaks backwards compatibility.

Backward compatibility with what exactly?  Please, be specific

|     Also, allowing
|
|  foo<auto>
|
|     and
|
|  new auto(1)
|
|     seems unnecessarily complicated.  Within templates,
| "typeof" solves most of those problems.

It does so only by creating more problems it has no solution for.
Please read the detail discussion in the several versions of the
proposal.

|     The one common idiom for which "let" is really needed
| is
|
|  for (let p = tab.begin(); p != tab.end(); p++)

And "let" is spelled "auto" in the proposal.  So your objection is
purelly about spelling?

| because the "typeof" form
|
|  for (typeof(tab.begin())::iterator p = tab.begin();
|   p != tab.end(); p++)
|
| is so bulky.  (Is that even legal?)
|
| One alternative would be to allow
|
|  for (iterator<tab> p = tab.begin(); p != tab.end(); p++)
|
| That's simple and understandable.

But we don't iterators that way. So it is not an option.



--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

gdr@cs.tamu.edu (Gabriel Dos Reis) wrote in message news:<m31xjip4j4.fsf@merlin.cs.tamu.edu>...
> tslettebo@hotmail.com (Terje Sletteb?) writes:
>
> | tslettebo@hotmail.com (Terje Sletteb?) wrote in message news:<b0491891.0407100446.431b3598@posting.google.com>...
> | >
> | > "decltype" consists of an abbreviation (short for "declared type"),
> | > whereas "typeof" does not. There's a preference in modern programming
> | > to use clear, descriptive names. It may therefore be better to use
> | > full words, rather than abbreviations, for keywords.
> |
> | Furthermore, what is the result of "decltype(a*b)"? The resulting type
> | might never have been declared!
>
> If "*" is overloaded, then it is the return type declared in the
> function declaration.

Well, ok. I was thinking of something like:

template<class T>
typename result_of<MyType<T> >::type operator+(const MyType &,const
MyType &);

However, I agree that it can be argued that "typename
result_of<MyType<T> >::type" is the declared type, even though the
type isn't actually determined, before compilation.

> | It could be synthesised as a result of
> | implicit template instantiations, deduced from the arguments.
>
> ?

I meant the above.

> | Secondly, how to read it? "Delared type a*b"? Shouldn't there be an
> | "of" in there (even if it's not declared, but might have had that
> | type, if it _had_ been declared...).
>
> The "of" is in the parenthesis.  It is common to read "f(x)" as
> "f of x", just like "vector<int>" is read "vector of int".
>
> | With "typeof(a*b)" it reads the way it is.
>
> Apart from the fact it does not necessarily do what decltype does,
> it reads "type of of a times b"; note redundant "of".

Yes, I understand this point, as well.

Regards,

Terje

P.S. This is exactly the reason for posting the question, to learn
about considerations and rationale for the given proposal. :)

---
[ 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                       ]

dickie@acm.org (Garth A. Dickie) writes:

| dave@boost-consulting.com (David Abrahams) wrote in message news:<uzn66qeia.fsf@boost-consulting.com>...
| > brangdon@cix.co.uk (Dave Harris) writes:
| >
| > > tslettebo@hotmail.com (Terje Sletteb?) wrote (abridged):
| > >> Regarding the "auto" part of the proposal, why not be able to name the
| > >> deduced type?
| > >>
| > >> auto type_name a1=f();
| > >> ..
| > >> type_name a2=g();
| > >>
| > > Is there any reason not to use typedef?
| > >
| > >     typedef decltype( f() ) type_name;
| > >     type_name a1 = f();
| > >     type_name a2 = g();
| >
| > Yes.  Repeated code is a maintenance and expressivity problem.  That
| > idiom forces you to repeat the expression f().  The expression is
| > short in this case, but could sometimes be much more complicated.
|
| There is a workaround for this particular example:
|
| auto         a1 = f();
| decltype(a1) a2 = g();

How many workarounds do you have for particular examples?  Leave alone
that int practice the involved expressions and variables are no
spelled f, g, a1, a2.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

daniel.frey@aixigo.de (Daniel Frey) writes:

| Marcin 'Qrczak' Kowalczyk wrote:
| > On Sun, 11 Jul 2004 18:17:38 +0000, Gabriel Dos Reis wrote:
| >
| >>decltype is reference-preserving, typeof as implemented in some
| >>existing compilers is not. They do not offer the same facilities.
| > I'm worried that with "int x; int &y = x;" decltype(x) is not the
| > same as
| > decltype(y). Aren't types of x and y completely equivalent in all other
| > cases?
|
| IIUC, you can add a small helper function to emulate the reference
| stripping typeof:
|
|    template< typename T > T strip( const T& );
|
| now:
|
|    decltype(strip(x)) equals decltype(strip(y))
|
| Maybe this (and probably some other small helpers) should be added to
| the proposal.

The proposal already contains a facility that does that
without requiring to solve more lexical problems.  That functionality
is what "auto" is supposed to do:  It deduces expression types -- much
like what you get from template-argument deduction.

| Or one might think about using type_traits directly, but
| this might be more typing for the user. I think we need to find out
| which helpers are required in practice...

And most importantly, look what the codes look when one has to
springle out traits.  If the proposed functionality had to be used
with traits even for the most simples cases, then something is wrong.

Yes, one can conceive of the minimal things to get the programs use
decltype (and I'm pretty sure the authors of the proposal know about
ways to accomplish that minimalism) -- just like we don't need
integers built-in in the language, what we'd need is just a way to count
parenthesis for example.  But it is handy to have a built-in integer,
for efficiency reasons.  Similarly, for easy-of-use purposes, it is
important that simple cases and common cases get "optimized".  This
proposal is not academic, it is designed to bring expressive power of
type-deduction to the practical programmer.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

AlbertoBarbati@libero.it (Alberto Barbati) writes:

| David Abrahams wrote:
| > brangdon@cix.co.uk (Dave Harris) writes:
| >>
| >>    typedef decltype( f() ) type_name;
| >>    type_name a1 = f();
| >>    type_name a2 = g();
| > Yes.  Repeated code is a maintenance and expressivity problem.  That
| > idiom forces you to repeat the expression f().  The expression is
| > short in this case, but could sometimes be much more complicated.
| >
|
| You can avoid duplicating the expression f() by writing:
|
|    auto a1 = f();
|    decltype(a1) a2 = g();

Yes, now you have to solve

  (1) a lexical problem: introduction of new superfluous names;
  (2) a type problem: make sure that you get an expression type, not
      a reference type for example.

Auto solves that problem in one step.

| which is not so bad and more expressive than the OP proposal, IMHO. If

until you pratice it in real codes.  Again consider simple use cases
as

     for (auto p = v.begin(); p != v.end(); ++p)
       // ...

Compare your workaround to the above.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

Gabriel Dos Reis wrote:
> nagle@animats.com (John Nagle) writes:
>
> | Terje Sletteb? wrote:
> | > Hi all.
> | > In proposal N1607
> | > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf),
> | > there's a proposal for two new keywords (or reuse of one, for another
> | > purpose, and a new keyword): "decltype" and "auto".
> |
> |
> |     On the "auto" front:
> |
> |     "let" has also been proposed for that purpose.  "let" is clearer.
> | but introduces a new keyword.  A problem with "auto" is that
> | is already an attribute, and valid in the same place as a type.
>
> Yes, an attribute with essentially no meaning.

    Still, it's in both C++ and C; it has to be formally taken out before
it can be reused incompatibly.
>
> I've had an experimental implementation of decltype and auto proposal
> in my GCC cxx-reflection-branch more than a year ago (and I've been
> having fruitful conversations with Peter Dimov who tried it on the the
> TR bind proposal).  Unfortunately, some unplanned succession of events
> led me unwillingly screw up the branch :-(  I'll try to restore it in
> usable state once I got some spare time [24 hours in a day is not
> enough]. But, the point that it is not difficult to implement -- you
> just need to remember that "auto" was used as a decl-specifier (and
> you have to do it anyway) and synthetize a "type variable" for which
> you find a value through the already existing template argument
> deduction machinery.
>
> |     Do you write
> |
> |  static auto i = x;
> |
> |     or
> |
> |  auto static i = x;
>
> Is it any different from
>
>       int static i = x;
>
> ?
>
> Don't forget that class storage specifiers are declaration specifiers,
> so they can appear in any order with other decl-specifiers.
>
> |     Is it legal to write
> |
> |  auto auto i = x;
> |
> | The proposed solution in the paper is to remove "auto" as
> | a storage class specifier, which breaks backwards compatibility.
>
> Backward compatibility with what exactly?  Please, be specific.

     auto int i;  // currently legal C and C++.

Yes, it's not very useful.  But look at the complaints back
in the "save the comma operator" thread, when I suggested
that "operator[]" have the same syntax as "operator()".
There's great hostility to breaking backwards compatibility.
This proposal both suggests removing the existing meaning of
"auto" and giving it a new, completely different meaning
in a single step.

How much code has been examined to determine whether "auto"
appears in any production code?  For the "operator[]" proposal,
we checked the in-house archive of GPLd software at IBM
Almaden, and the source that came with MSDN 6.  That wasn't
considered good enough.  What code base has been examined
for this proposal?

> | One alternative would be to allow
> |
> |  for (iterator<tab> p = tab.begin(); p != tab.end(); p++)
> |
> | That's simple and understandable.
>
> But we don't iterators that way. So it is not an option.

    "But we don't iterators that way"?  Don't what?

    John Nagle
    Animats

---
[ 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                       ]

nagle@animats.com (John Nagle) writes:

| Gabriel Dos Reis wrote:
| > nagle@animats.com (John Nagle) writes:
| > | Terje Sletteb? wrote:
| > | > Hi all.
| > | > In proposal N1607
| > | > (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf),
| > | > there's a proposal for two new keywords (or reuse of one, for another
| > | > purpose, and a new keyword): "decltype" and "auto".
| > | | |     On the "auto" front:
| > | |     "let" has also been proposed for that purpose.  "let" is
| > clearer.
| > | but introduces a new keyword.  A problem with "auto" is that
| > | is already an attribute, and valid in the same place as a type.
| > Yes, an attribute with essentially no meaning.
|
|     Still, it's in both C++ and C;

It is in both C and C++, nobody is disputing that.  The fact is that,
implicit int is invalid in C++.  Consequently, as of today, you can't
write any valid program at the intersection of the two languages and
use "auto" that has any meaning that would differ from

  #define auto

| it has to be formally taken out before

No, it does not.

| it can be reused incompatibly.

It is NOT an incompatible reuse.  You can still say

    auto int x = 9043431;

The proposal does not make that invalid.

[...]

| > |     Is it legal to write
| > | |  auto auto i = x;
| > | | The proposed solution in the paper is to remove "auto" as
| > | a storage class specifier, which breaks backwards compatibility.
| > Backward compatibility with what exactly?  Please, be specific.
|
|      auto int i;  // currently legal C and C++.
|
| Yes, it's not very useful.

and harmeless.  The proposal does not remove that.  In other words,
the proposal does not break nor change the meaning of such constructs.

|  But look at the complaints back
| in the "save the comma operator" thread, when I suggested
| that "operator[]" have the same syntax as "operator()".

I looked back but I fail to see the connection.  In your past
suggestions, you're proposing to break existing meaning.  The
auto/decltype proposal does not do that.  You can still continue to
use auto as in the past (according to standard C++), you'll not get
compiler error nor semantics change.

| There's great hostility to breaking backwards compatibility.

Yes.  But the two situations are not similar.  The auto proposal does
not change the meaning of existing programs that use auto in standard
conformant way.

| This proposal both suggests removing the existing meaning of

Can you provide specific quote of where it suggests to remove the
meaning of existing auto?

| "auto" and giving it a new, completely different meaning
| in a single step.

What I read in the proposal is a generalization of the existing
meaning, no removal.  But perhaps you'll provide the quote I'm
missing.

| How much code has been examined to determine whether "auto"
| appears in any production code?

That is irrelevant, as the proposal does not change the meaning of auto
in the way it is currently permitted.

[...]

| > | One alternative would be to allow
| > | |  for (iterator<tab> p = tab.begin(); p != tab.end(); p++)
| > | | That's simple and understandable.
| > But we don't iterators that way. So it is not an option.
|
|     "But we don't iterators that way"?  Don't what?

Sorry, I meant:  "But we don't have iterators that way".

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

Gabriel Dos Reis wrote:
> AlbertoBarbati@libero.it (Alberto Barbati) writes:
>
> | David Abrahams wrote:
> | > brangdon@cix.co.uk (Dave Harris) writes:
> | >>
> | >>    typedef decltype( f() ) type_name;
> | >>    type_name a1 = f();
> | >>    type_name a2 = g();
> | > Yes.  Repeated code is a maintenance and expressivity problem.  That
> | > idiom forces you to repeat the expression f().  The expression is
> | > short in this case, but could sometimes be much more complicated.
> | >
> |
> | You can avoid duplicating the expression f() by writing:
> |
> |    auto a1 = f();
> |    decltype(a1) a2 = g();
>
> Yes, now you have to solve
>
>   (1) a lexical problem: introduction of new superfluous names;

There were one superfluous in the OP's code, but I don't see any
superfluous name in mine.

>   (2) a type problem: make sure that you get an expression type, not
>       a reference type for example.

The only *real* problem I see is if f() returns a non-const reference
and g() returns something that cannot be bound to a non-const reference.
All other cases involving references look ok to me, although I agree
that the code gets a bit too much involuted.

Anyway, see below...

>
> Auto solves that problem in one step.
>
> | which is not so bad and more expressive than the OP proposal, IMHO. If
>
> until you pratice it in real codes.  Again consider simple use cases
> as
>
>      for (auto p = v.begin(); p != v.end(); ++p)
>        // ...
>
> Compare your workaround to the above.
>

Perhaps I didn't express myself very well. First of all, I agree with
you that a better code (or, at least, the one I would write) in the
above case would be:

   auto a1 = f();
   auto a2 = g();

My "workaround" was *only* in response to the OP's suggestion to allow
the auto statement to declare the underlying type, as in

   auto a1_type a1 = f();

My belief is that this syntax is unnecessary, because the same effect
can be obtained without it, in a more expressive way that does not
introduce superfluous names. That's what my code was for. This remark
does NOT make this idiom (either in my form or the OP's form) a "best
practice" and I am NOT suggesting its usefulness in a broad sense. In
fact, it presents a few problems that the plain use of auto solves more
nicely.

I hope my thoughts are more clearly expressed now.

Alberto

---
[ 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                       ]

In article <m3wu17e8wx.fsf@merlin.cs.tamu.edu>, Gabriel Dos Reis
<gdr@cs.tamu.edu> writes
>It is in both C and C++, nobody is disputing that.  The fact is that,
>implicit int is invalid in C++.  Consequently, as of today, you can't
>write any valid program at the intersection of the two languages and
>use "auto" that has any meaning that would differ from

Actually C removed implicit int as well.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ 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                       ]

"Gabriel Dos Reis" <gdr@cs.tamu.edu> wrote in message
news:m3k6xarb25.fsf@merlin.cs.tamu.edu...

> decltype is reference-preserving, typeof as implemented in some
> existing compilers is not. They do not offer the same facilities.
> You did not _explain_ why both should not be there.

Definitely.  Different tasks need a ref-dropping in some cases and
preserving in others. And ability to use the ref-dropping variant with [cv]
and &. I hope C++0x will gain all of them, not settling on some half-baked
solution.

Paul


---
[ 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                       ]

nagle@animats.com (John Nagle) wrote in message news:<4ZyIc.19517$Fp3.12440@newssvr27.news.prodigy.com>...
..
> The proposed solution in the paper is to remove "auto" as
> a storage class specifier, which breaks backwards compatibility.

In principle, yes. In practice, who uses "auto", and why? It does
nothing that it's absence doesn't do equally well. That's why it's a
good choice for this context: its a nice short word that will almost
never have been used with a meaning that conflicts with the current
one.

---
[ 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                       ]

Gabriel Dos Reis wrote:

> nagle@animats.com (John Nagle) writes:
>
> Can you provide specific quote of where it suggests to remove the
> meaning of existing auto?

   "8.2 Removing auto as storage specifier - proposed text"
    ...
    Remove reference to auto...
    ...
    Remove auto as a storage class specifier and the discussion
about auto from paragraph 2.
    ...
    Remove auto ...
    ...
    Remove auto ...

The proposal definitely removes the existing meaning of "auto"
completely.

    On a related note, it looks like "decltype" preserves
attributes such as "const".  This would imply that

 const int n=100;
 auto x = n;  // tab.begin returns a const

would yield a "x" which is const.  Is that the intent?

This has some annoying implications for dynamic assignment of
iterators from "collectionname.begin()", which, I think, is
a const value.

> | > | One alternative would be to allow
> | > | |  for (iterator<tab> p = tab.begin(); p != tab.end(); p++)
> | > | | That's simple and understandable.
> | > But we don't iterators that way. So it is not an option.
> |
> |     "But we don't iterators that way"?  Don't what?
>
> Sorry, I meant:  "But we don't have iterators that way".

    Can you write a template to do that in C++ today?  Can you
do it if you have "typeof", or "decltype"?  If not, why not?

    John Nagle
    Animats

---
[ 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 all.

In proposal N1607 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf),
there's a proposal for two new keywords (or reuse of one, for another
purpose, and a new keyword): "decltype" and "auto".

In the proposal, it says: "The semantics of the proposed version of
the typeof operator reflects the declared type of the argument.
Therefore, we propose that the operator be named decltype."

I hardly think this is good enough reason to change the name of a
"keyword" that has been a defacto standard extension for years:
"typeof". Even if the current implementations of "typeof" (GCC and
EDG) has reference-dropping semantics, there's probably no point in
having both "typeof" and "decltype" in the language. Thus, I propose
that the new keyword remains "typeof", not "decltype".

"decltype" consists of an abbreviation (short for "declared type"),
whereas "typeof" does not. There's a preference in modern programming
to use clear, descriptive names. It may therefore be better to use
full words, rather than abbreviations, for keywords.

Furthermore, if the N1607 proposal gets accepted, the semantics of
"typeof" could be changed in the compilers that now has it as an
extension. After all, as it's currently an extension (not
standardised), I don't think this should be used as an argument for
not using the same keyword, if it becomes standardised, even with
slightly changed semantics.

Part of the agenda of standardisation committees is to standardise
existing practice (another part is innovation), and as "typeof" has
for years been a defacto standard extension, why not keep it?

It also gives a nice symmetry with "sizeof", which arguably does the
same (deduces the type), and gets its size.

Regarding the "auto" part of the proposal, why not be able to name the
deduced type?

auto type_name a1=f();
..
type_name a2=g();


Regards,

Terje

---
[ 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                       ]

tslettebo@hotmail.com (Terje Sletteb?) writes:

| Hi all.
|
| In proposal N1607 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf),
| there's a proposal for two new keywords (or reuse of one, for another
| purpose, and a new keyword): "decltype" and "auto".
|
| In the proposal, it says: "The semantics of the proposed version of
| the typeof operator reflects the declared type of the argument.
| Therefore, we propose that the operator be named decltype."

When this type-inquiry idea was first discussed in EWG, it was at the
Oxford meeting (and there was no _written_ proposal yet). Bjarne
explained the idea, then we spent a fair amount of time considering
the spelling -- there was near a dozen of potential keywords.  "typeof"
was among them, it did not get the majority of the votes.  I think the
first version of the proposal reflected the outcome of the discussions
in Oxford.

Personnally, I vote for leaving the "typeof" extension keyword alone.
I would hate to see the functionality offered by the proposal get
polluted for "compatibility reasons".

Please, also notice that if you consider the semantics, then "typeof"
is more close to "auto" than to "decltype".

| I hardly think this is good enough reason to change the name of a
| "keyword" that has been a defacto standard extension for years:
| "typeof". Even if the current implementations of "typeof" (GCC and
| EDG) has reference-dropping semantics, there's probably no point in
| having both "typeof" and "decltype" in the language. Thus, I propose
| that the new keyword remains "typeof", not "decltype".

decltype is reference-preserving, typeof as implemented in some
existing compilers is not. They do not offer the same facilities.
You did not _explain_ why both should not be there.

| "decltype" consists of an abbreviation (short for "declared type"),
| whereas "typeof" does not.

Yes.  The spelling "decltype" reflects the intent of the operator.
When you ask for the "type of" an expression, you get back something
that is not necessarily the "declared type" -- i.e. you get something
that is not a reference type.  Therefore I consider "decltype" be
consistent with its semantics.

| There's a preference in modern programming
| to use clear, descriptive names.

That is what "decltype" is.

| It may therefore be better to use
| full words, rather than abbreviations, for keywords.

You mean "declared_type"?  It is a possibility (which was probably
suggested at the Oxford meeting).

| Furthermore, if the N1607 proposal gets accepted, the semantics of
| "typeof" could be changed in the compilers that now has it as an
| extension.

But that would be after the fact, not before.

| After all, as it's currently an extension (not
| standardised), I don't think this should be used as an argument for
| not using the same keyword, if it becomes standardised, even with
| slightly changed semantics.

Then, you'd be surprised -- and of course, I don't believe you.
I could cite the hash_map case as a counter-example to your
assertion.

| Part of the agenda of standardisation committees is to standardise
| existing practice (another part is innovation), and as "typeof" has
| for years been a defacto standard extension, why not keep it?

Standardizing existing practice in this case would mean that we have
something that is not reference-preserving which does not cover the
ground. In fact, the semantics of "typeof" is in some current
implementations would be standardized, and the bonus is that it would
not need a new keyword.  It would called "auto".

| It also gives a nice symmetry with "sizeof", which arguably does the
| same (deduces the type), and gets its size.

But the symmettry argument was used in the design of "typeof" to be
non-reference preserving.  If standardized "typeof" would have to be
reference-preserving, then:

  (1) it would not be standardization of existing pratice as you
      suggested;

  (2) there would not be that symmetry anymore.

I make the conjecture that we'll see a posting to this group
saying that in the name of symmetry and existing practice,
"typeof" should not be reference-preserving. That would be in the
tradition of the classic pattern when a useful functionality gets
polluted by focus on syntax.


[ And, personally I really dislike the "of" in both "sizeof" and
  "typeof" -- just like in result_of.  I find it redundant and
  inelegant. ]

| Regarding the "auto" part of the proposal, why not be able to name the
| deduced type?

Actually, "auto" is just another name for "typeof", if you carefully
look at the semantics.

| auto type_name a1=f();
| ..
| type_name a2=g();

The ability to name the deduced type has been raised in several
discussions about the EWG.  It just did not seem as important as the
basic facility.  I'm confident that once we have the basic facility in
place, if more advanced, less frequently used, aspects are needed they
would be considered.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

tslettebo@hotmail.com (Terje Sletteb?) wrote in message news:<b0491891.0407100446.431b3598@posting.google.com>...
>
> "decltype" consists of an abbreviation (short for "declared type"),
> whereas "typeof" does not. There's a preference in modern programming
> to use clear, descriptive names. It may therefore be better to use
> full words, rather than abbreviations, for keywords.

Furthermore, what is the result of "decltype(a*b)"? The resulting type
might never have been declared! It could be synthesised as a result of
implicit template instantiations, deduced from the arguments.
Secondly, how to read it? "Delared type a*b"? Shouldn't there be an
"of" in there (even if it's not declared, but might have had that
type, if it _had_ been declared...).

With "typeof(a*b)" it reads the way it is.

Regards,

Terje

---
[ 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                       ]

On Sun, 11 Jul 2004 18:17:38 +0000, Gabriel Dos Reis wrote:

> decltype is reference-preserving, typeof as implemented in some
> existing compilers is not. They do not offer the same facilities.

I'm worried that with "int x; int &y = x;" decltype(x) is not the same as
decltype(y). Aren't types of x and y completely equivalent in all other
cases?

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


---
[ 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                       ]

tslettebo@hotmail.com (Terje Sletteb?) wrote (abridged):
> Regarding the "auto" part of the proposal, why not be able to name the
> deduced type?
>
> auto type_name a1=f();
> ..
> type_name a2=g();

The intent of the first line wouldn't be very clear. We can already write:
    auto int a1 = f();

so is:
    auto itn a1 = f();

a typo or an attempt to declare type itn? It's the moral equivalent of
being able to use variables without declaring them, only with types
instead of variables. Is there any reason not to use typedef?

    typedef decltype( f() ) type_name;
    type_name a1 = f();
    type_name a2 = g();

-- Dave Harris, Nottingham, UK

---
[ 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                       ]

brangdon@cix.co.uk (Dave Harris) writes:

> tslettebo@hotmail.com (Terje Sletteb?) wrote (abridged):
>> Regarding the "auto" part of the proposal, why not be able to name the
>> deduced type?
>>
>> auto type_name a1=f();
>> ..
>> type_name a2=g();
>
> The intent of the first line wouldn't be very clear. We can already write:
>     auto int a1 = f();
>
> so is:
>     auto itn a1 = f();
>
> a typo or an attempt to declare type itn? It's the moral equivalent of
> being able to use variables without declaring them, only with types
> instead of variables. Is there any reason not to use typedef?
>
>     typedef decltype( f() ) type_name;
>     type_name a1 = f();
>     type_name a2 = g();

Yes.  Repeated code is a maintenance and expressivity problem.  That
idiom forces you to repeat the expression f().  The expression is
short in this case, but could sometimes be much more complicated.

--
Dave Abrahams
Boost Consulting
http://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                       ]

qrczak@knm.org.pl ("Marcin 'Qrczak' Kowalczyk") writes:

| On Sun, 11 Jul 2004 18:17:38 +0000, Gabriel Dos Reis wrote:
|
| > decltype is reference-preserving, typeof as implemented in some
| > existing compilers is not. They do not offer the same facilities.
|
| I'm worried that with "int x; int &y = x;" decltype(x) is not the same as
| decltype(y).

Yes, that is by design.

| Aren't types of x and y completely equivalent in all other
| cases?

No, they are not completely equivalent in all other cases.  Consider

    struct S {
       int& x;
    };

for example.

decltype is fundamentally designed to return the declared type.
This type need not correspond to the expression type -- which can't be
a reference type for example.  Since the need for that kind of type is
fully acknowledged, "auto" is provided to cover the ground.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

* Terje Sletteb?:

> Furthermore, if the N1607 proposal gets accepted, the semantics of
> "typeof" could be changed in the compilers that now has it as an
> extension. After all, as it's currently an extension (not
> standardised), I don't think this should be used as an argument for
> not using the same keyword, if it becomes standardised, even with
> slightly changed semantics.

It's a documented extension in some compilers, so it has to be
supported for some time with its old semantics.  This is very painful
if the new keyword uses the same name.

---
[ 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                       ]

tslettebo@hotmail.com (Terje Sletteb?) writes:

| tslettebo@hotmail.com (Terje Sletteb?) wrote in message news:<b0491891.0407100446.431b3598@posting.google.com>...
| >
| > "decltype" consists of an abbreviation (short for "declared type"),
| > whereas "typeof" does not. There's a preference in modern programming
| > to use clear, descriptive names. It may therefore be better to use
| > full words, rather than abbreviations, for keywords.
|
| Furthermore, what is the result of "decltype(a*b)"? The resulting type
| might never have been declared!

If "*" is overloaded, then it is the return type declared in the
function declaration.

| It could be synthesised as a result of
| implicit template instantiations, deduced from the arguments.

?

| Secondly, how to read it? "Delared type a*b"? Shouldn't there be an
| "of" in there (even if it's not declared, but might have had that
| type, if it _had_ been declared...).

The "of" is in the parenthesis.  It is common to read "f(x)" as
"f of x", just like "vector<int>" is read "vector of int".

| With "typeof(a*b)" it reads the way it is.

Apart from the fact it does not necessarily do what decltype does,
it reads "type of of a times b"; note redundant "of".

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

brangdon@cix.co.uk (Dave Harris) writes:

| tslettebo@hotmail.com (Terje Sletteb?) wrote (abridged):
| > Regarding the "auto" part of the proposal, why not be able to name the
| > deduced type?
| >
| > auto type_name a1=f();
| > ..
| > type_name a2=g();
|
| The intent of the first line wouldn't be very clear. We can already write:
|     auto int a1 = f();
|
| so is:
|     auto itn a1 = f();
|
| a typo or an attempt to declare type itn? It's the moral equivalent of
| being able to use variables without declaring them, only with types
| instead of variables. Is there any reason not to use typedef?
|
|     typedef decltype( f() ) type_name;
|     type_name a1 = f();
|     type_name a2 = g();

Yes: decltype is reference-preserving and auto is not.

Also, the need for circumvoluted typedefs is unnecessary verbority --
i.e. more opportunities to make mistakes or to get things out of sync.

--
                                                        Gabriel Dos Reis
                                                         gdr@cs.tamu.edu
  Texas A&M University -- Computer Science Department
 301, Bright Building -- College Station, TX 77843-3112

---
[ 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                       ]

dave@boost-consulting.com (David Abrahams) wrote in message news:<uzn66qeia.fsf@boost-consulting.com>...
> brangdon@cix.co.uk (Dave Harris) writes:
>
> > tslettebo@hotmail.com (Terje Sletteb?) wrote (abridged):
> >> Regarding the "auto" part of the proposal, why not be able to name the
> >> deduced type?
> >>
> >> auto type_name a1=f();
> >> ..
> >> type_name a2=g();
> >
> > The intent of the first line wouldn't be very clear. We can already write:
> >     auto int a1 = f();
> >
> > so is:
> >     auto itn a1 = f();
> >
> > a typo or an attempt to declare type itn? It's the moral equivalent of
> > being able to use variables without declaring them, only with types
> > instead of variables. Is there any reason not to use typedef?
>
> >     typedef decltype( f() ) type_name;
> >     type_name a1 = f();
> >     type_name a2 = g();
>
> Yes.  Repeated code is a maintenance and expressivity problem.  That
> idiom forces you to repeat the expression f().  The expression is
> short in this case, but could sometimes be much more complicated.

Besides, how many uses "auto" nowadays...? After all, it's an optional
keyword. Even if it's used somewhere, a compiler might warn if the
deduced type isn't used elsewhere (as in the case of the typo).

Regards,

Terje

---
[ 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                       ]

tslettebo@hotmail.com (Terje Sletteb?) wrote in message news:<b0491891.0407110501.19acb957@posting.google.com>...
..
> Furthermore, what is the result of "decltype(a*b)"? The resulting type
> might never have been declared! It could be synthesised as a result of

There are two main cases:
1. a and b are both standard-defined or implementation-define
arithmetic types, for which a*b has a standard- or
implementation-defined type. In this case, it is indeed possible that
the result type had never been declared in that program. But so what?

2. a*b invokes a user-defined operator overload, which must therefore
have been declared in-scope, including it's return type. Therefore,
the type must have been declared in scope. It might have been declared
inside an implicit template instantion, but it was still declared.

---
[ 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                       ]

dave@boost-consulting.com (David Abrahams) wrote in message news:<uzn66qeia.fsf@boost-consulting.com>...
> brangdon@cix.co.uk (Dave Harris) writes:
>
> > tslettebo@hotmail.com (Terje Sletteb?) wrote (abridged):
> >> Regarding the "auto" part of the proposal, why not be able to name the
> >> deduced type?
> >>
> >> auto type_name a1=f();
> >> ..
> >> type_name a2=g();
> >>
> > Is there any reason not to use typedef?
> >
> >     typedef decltype( f() ) type_name;
> >     type_name a1 = f();
> >     type_name a2 = g();
>
> Yes.  Repeated code is a maintenance and expressivity problem.  That
> idiom forces you to repeat the expression f().  The expression is
> short in this case, but could sometimes be much more complicated.

There is a workaround for this particular example:

auto         a1 = f();
decltype(a1) a2 = g();

---
[ 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                       ]

Marcin 'Qrczak' Kowalczyk wrote:
> On Sun, 11 Jul 2004 18:17:38 +0000, Gabriel Dos Reis wrote:
>=20
>=20
>>decltype is reference-preserving, typeof as implemented in some
>>existing compilers is not. They do not offer the same facilities.
>=20
>=20
> I'm worried that with "int x; int &y =3D x;" decltype(x) is not the sam=
e as
> decltype(y). Aren't types of x and y completely equivalent in all other
> cases?

IIUC, you can add a small helper function to emulate the reference=20
stripping typeof:

   template< typename T > T strip( const T& );

now:

   decltype(strip(x)) equals decltype(strip(y))

Maybe this (and probably some other small helpers) should be added to=20
the proposal. Or one might think about using type_traits directly, but=20
this might be more typing for the user. I think we need to find out=20
which helpers are required in practice...

Regards, Daniel

[ And as a half-serious idea: #define TYPEOF(x) decltype(strip(x)) ]

--=20
Daniel Frey

aixigo AG - financial solutions & technology
Schlo=DF-Rahe-Stra=DFe 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de


---
[ 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:
> brangdon@cix.co.uk (Dave Harris) writes:
>>
>>    typedef decltype( f() ) type_name;
>>    type_name a1 = f();
>>    type_name a2 = g();
>
>
> Yes.  Repeated code is a maintenance and expressivity problem.  That
> idiom forces you to repeat the expression f().  The expression is
> short in this case, but could sometimes be much more complicated.
>

You can avoid duplicating the expression f() by writing:

   auto a1 = f();
   decltype(a1) a2 = g();

which is not so bad and more expressive than the OP proposal, IMHO. If
the type is being used several times, you can still use a typedef

   auto a1 = f();
   typedef decltype(a1) a1_type;
   a1_type a2 = g();

This construct, however, supports one of the OP's objections: the type
of a1 is never really "declared" so does it make sense use the keyword
decltype to get its "declared type"?

However, I object the OP's statement that "typeof" is a de facto
standard, as it's implemented as an extension on a quite limited number
of compilers (although this number includes very authoritative ones). On
the contrary, I think that this fact makes the keyword no longer
suitable because changing its semantic would create a lot of confusion
and a backward compatibility hell for all programmers that are currently
using it. I would add that it had been unwise for such compilers to have
used such a keyword in the first place. It would have been better to use
an implementation-reserved string such as __typeof to avoid the current
embarassment.

Alberto

---
[ 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                       ]