 |
C++Talk.NET
C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Terje Sletteb?
Guest
|
 Posted: Sun Jul 11, 2004 5:33 am Post subject: Why "decltype" and not "typeof" in proposal? |
 |
|
Hi all.
In proposal N1607 ([url]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf)[/url],
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 ]
|
|
| Back to top |
|
 |
Gabriel Dos Reis
Guest
|
| Posted: Sun Jul 11, 2004 6:17 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
[email]tslettebo (AT) hotmail (DOT) com[/email] (Terje Sletteb?) writes:
| Quote: | Hi all.
In proposal N1607 ([url]http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1607.pdf)[/url],
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".
| Quote: | 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.
| Quote: | "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.
| Quote: | There's a preference in modern programming
to use clear, descriptive names.
|
That is what "decltype" is.
| Quote: | 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).
| Quote: | 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.
| Quote: | 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.
| Quote: | 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".
| Quote: | 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. ]
| Quote: | 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.
| Quote: | 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
[email]gdr (AT) cs (DOT) tamu.edu[/email]
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 ]
|
|
| Back to top |
|
|
Terje Sletteb?
Guest
|
| Posted: Sun Jul 11, 2004 6:17 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
[email]tslettebo (AT) hotmail (DOT) com[/email] (Terje Sletteb?) wrote in message news:<b0491891.0407100446.431b3598 (AT) posting (DOT) google.com>...
| Quote: |
"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 ]
|
|
| Back to top |
|
|
Marcin 'Qrczak' Kowalczyk
Guest
|
| Posted: Sun Jul 11, 2004 9:46 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
On Sun, 11 Jul 2004 18:17:38 +0000, Gabriel Dos Reis wrote:
| Quote: | 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
__/ [email]qrczak (AT) knm (DOT) org.pl[/email]
^^ 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 ]
|
|
| Back to top |
|
|
Dave Harris
Guest
|
| Posted: Sun Jul 11, 2004 11:44 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
[email]tslettebo (AT) hotmail (DOT) com[/email] (Terje Sletteb?) wrote (abridged):
| Quote: | 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 ]
|
|
| Back to top |
|
|
David Abrahams
Guest
|
| Posted: Mon Jul 12, 2004 12:26 am Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
[email]brangdon (AT) cix (DOT) co.uk[/email] (Dave Harris) writes:
| Quote: | tslettebo (AT) hotmail (DOT) 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 ]
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Mon Jul 12, 2004 3:05 am Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
[email]qrczak (AT) knm (DOT) org.pl[/email] ("Marcin 'Qrczak' Kowalczyk") writes:
| Quote: | 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.
| Quote: | 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
[email]gdr (AT) cs (DOT) tamu.edu[/email]
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 ]
|
|
| Back to top |
|
|
Florian Weimer
Guest
|
| Posted: Mon Jul 12, 2004 9:32 am Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
* Terje Sletteb?:
| Quote: | 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 ]
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Mon Jul 12, 2004 3:29 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
[email]tslettebo (AT) hotmail (DOT) com[/email] (Terje Sletteb?) writes:
| Quote: | tslettebo (AT) hotmail (DOT) com (Terje Sletteb?) wrote in message news:<b0491891.0407100446.431b3598 (AT) posting (DOT) 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.
| Quote: | It could be synthesised as a result of
implicit template instantiations, deduced from the arguments.
|
?
| Quote: | 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".
| Quote: | 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
[email]gdr (AT) cs (DOT) tamu.edu[/email]
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 ]
|
|
| Back to top |
|
|
Gabriel Dos Reis
Guest
|
| Posted: Mon Jul 12, 2004 3:29 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
[email]brangdon (AT) cix (DOT) co.uk[/email] (Dave Harris) writes:
| Quote: | tslettebo (AT) hotmail (DOT) 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
[email]gdr (AT) cs (DOT) tamu.edu[/email]
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 ]
|
|
| Back to top |
|
|
Terje Sletteb?
Guest
|
| Posted: Mon Jul 12, 2004 3:30 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
[email]dave (AT) boost-consulting (DOT) com[/email] (David Abrahams) wrote in message news:<uzn66qeia.fsf (AT) boost-consulting (DOT) com>...
| Quote: | brangdon (AT) cix (DOT) co.uk (Dave Harris) writes:
[email]tslettebo (AT) hotmail (DOT) com[/email] (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 ]
|
|
| Back to top |
|
|
James Kuyper
Guest
|
| Posted: Mon Jul 12, 2004 3:30 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
[email]tslettebo (AT) hotmail (DOT) com[/email] (Terje Sletteb?) wrote in message news:<b0491891.0407110501.19acb957 (AT) posting (DOT) google.com>...
...
| Quote: | 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 ]
|
|
| Back to top |
|
|
Garth A. Dickie
Guest
|
| Posted: Mon Jul 12, 2004 4:26 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
[email]dave (AT) boost-consulting (DOT) com[/email] (David Abrahams) wrote in message news:<uzn66qeia.fsf (AT) boost-consulting (DOT) com>...
| Quote: | brangdon (AT) cix (DOT) co.uk (Dave Harris) writes:
[email]tslettebo (AT) hotmail (DOT) com[/email] (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 ]
|
|
| Back to top |
|
|
Daniel Frey
Guest
|
| Posted: Mon Jul 12, 2004 4:53 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
Marcin 'Qrczak' Kowalczyk wrote:
| Quote: | 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. 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...
Regards, Daniel
[ And as a half-serious idea: #define TYPEOF(x) decltype(strip(x)) ]
--
Daniel Frey
aixigo AG - financial solutions & technology
Schloß-Rahe-Straße 15, 52072 Aachen, Germany
fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99
eMail: [email]daniel.frey (AT) aixigo (DOT) de[/email], 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 ]
|
|
| Back to top |
|
|
Alberto Barbati
Guest
|
| Posted: Mon Jul 12, 2004 4:54 pm Post subject: Re: Why "decltype" and not "typeof" in proposal? |
|
|
David Abrahams wrote:
| Quote: | brangdon (AT) cix (DOT) 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 ]
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
