Re: Type traits and accessibility
On 25 Apr, 04:05, Daniel Krugler <daniel.krueg...@googlemail.com>
wrote:
On 23 Apr., 01:22, Nikolay Ivchenkov <ts...@mail.ru> wrote:
This discussions starts to cycle a bit. I tried to point out that
the definition of is_constructible refers to the ill-formed state
from a program that can be deduced from this partially defined
program. I also tried to make clear that any completing program
may contain constructs that would - in combination with this
partial program - still cause an ill-formed program, among
these reasons are that the completed program may omit
the definition of a used entity. These other defects are unrelated
to the definition of is_constructible - in particular unrelated
to the reference of an ill-formed expression within this partial
program. IMO the current wording is clear and unambiguous in
this regard.
There is a big difference between the current wording and the
following
[begin]
Given the following function prototype:
template <class T>
typename add_rvalue_reference<T>::type create();
the predicate condition for a template specialization
is_constructible<T, Args...> shall be satisfied if and only if
[removed]the following expression CE would be well-formed:[/removed]
[inserted]at the point of instantiation for the template
specialization the declaration of the form
typedef decltype(CE) unique_name;
would be well-formed, where unique_name is an identifier that differs
from any other identifier in the program, and CE is an expression of
the following form:[/inserted]
[...]
[inserted]For the purposes of this rule a declaration is considered to
be ill-formed if and only if it causes the entire program to be ill-
formed according to diagnosable rules and this fact can be established
without considering all parts of the program except the declaration
itself and the contiguous portion of program text between the
beginning of the translation unit where the declaration resides and
the declaration; otherwise for the purposes of this rule the
declaration is considered to be well-formed.[/inserted]
[/end]
which could be considered as evidence for your explanation (if my
understanding of your explanation is right) when 14.6.4.1 [temp.point]
is properly modified as shown below:
[begin]
For a class template specialization, a class member template
specialization, or a specialization for a class member of a class
template, if the specialization is implicitly instantiated because it
is referenced from within another template specialization, if the
context from which the specialization is referenced depends on a
template parameter, and if the specialization is not instantiated
previous to the instantiation of the enclosing template, the point of
instantiation is immediately before the point of instantiation of the
enclosing template. [inserted]Otherwise, if any template type argument
of such a specialization is a local type, the point of instantiation
for the specialization immediately precedes the innermost statement
that refers to the specialization.[/inserted] Otherwise, the point of
instantiation for such a specialization immediately precedes the
namespace scope declaration or definition that refers to the
specialization.
A local type is a local class or enumeration, or a type compounded
from at least one local type, or a class template specialization where
at least one template type argument is a local type.
[/end]
(Certain cases may still be uncovered)
Example 1:
#include <iostream>
#include <type_traits>
#include <typeinfo>
struct A
{
template <class T, class U = decltype(typeid(T))>
A(T *);
};
int main()
{
class X;
// the point of instantiation should be here
std::cout << std::is_constructible<A, X *>::value;
class X {};
}
Example 2:
#include <iostream>
#include <type_traits>
#include <typeinfo>
struct A
{
template <class T, class U = decltype(typeid(T))>
A(T *);
};
int main()
{
class X;
class X {};
// the point of instantiation should be here
std::cout << std::is_constructible<A, X *>::value;
}
Referring to your example of "std::is_constructible<int &>::value"
I do not see this problem, because the given
typedef int& T;
the construction
T()
does cause the program to be instantaneously ill-formed
I didn't understand this. What does "instantaneously ill-formed" mean?
This situation cannot be compared with
struct X { X(int); };
applied to the construction
static_cast<X>(create<int>())
because the expression itself is potentially well-formed.
I could say that an expression in which undefined function or object
is used is always ill-formed. In the following example
int f();
int main()
{
sizeof f(); // (1)
f(); // (2)
}
the former expression f() is not potentially-evaluated, but the latter
expression f() is potentially-evaluated, so, these expressions can be
considered as non-equivalent.
#include <typeinfo>
int main()
{
class X;
typeid(X); // renders the program ill-formed
class X {};
typeid(X); // OK
}
According to your opinion, the former expression typeid(X) is ill-
formed, but the latter expression typeid(X) is well-formed. In any
case we shall consider a context where the expression resides.
The fact that the program could be *potentially* ill-formed
if any definition of a used entity - like that of the
constructor X::X(int) or that of the specialization
int&& create<int>() - is missing can only be deduced from
a completed program.
In some particular cases similar ill-formedness can be determined
immediately:
int main()
{
struct Local
{
Local();
// cannot be defined outside
};
Local();
// renders the program ill-formed;
// it could be diagnosed right here
}
What is the "additional programming error"? For example:
#include <typeinfo>
class X;
int main()
{
typeid(X);
}
May the missing definition of X be considered as "additional
programming error"?
I don't understand this example in combination with
the discussion of the definition of is_constructible.
The well-formedness of a typeid expression with dependent operand
could affect the value of is_constructible<T, Args...>::value. For
example:
#include <iostream>
#include <type_traits>
#include <typeinfo>
class X;
struct A
{
template <class T, class U = decltype(typeid(T))>
A(T *);
};
int main()
{
std::cout << std::is_constructible<A, X *>::value;
// ?
}
If the well-formedness of the expression typeid(T), where T is
considered to be incomplete class type X, is unspecified then the
value of std::is_constructible<A, X *>::value is also unspecified.
Similarly, the following program
#include <typeinfo>
class X;
int main()
{
typeid(X);
}
is ill-formed because:
1) the class type X is used as the operand of the typeid operator
(i.e. in the context where it is required to be completely-defined),
and
2) the definition of the class X is not provided prior to the typeid
expression.
Is the expression typeid(X) well-formed?
It is clearly ill-formed
It is not obvious.
According to [expr.typeid]/3:
"[..] If the type of the expression is a class type, the class
shall be completely-defined. [..]"
which is a requirement to the implementation to diagnose
a violation, see also [intro.compliance]/1+2.
There is only one obvious consequence from the rules you showed: the
entire program is ill-formed. I asked you about the expression's well-
formedness.
I don't see the situation you tried to show above as a situation
of an unspecified ill-formedness. The usage of typeid(X) is clearly
ill-formed, similarly as that of sizeof(X) for an undefined entity X.
If you think that this is not clear from the standard, this is a
different issue, I believe.
Yes, I think that this is not clear from the specification.
Defects of the C++ specification are supposed to be main subject here.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]