Clang seems to agree, but not the others: https://godbolt.org/z/41q4vszP8.

[basic.life] says

The lifetime of an object o of type T ends when:
(1.3) if T is a non-class type, the object is destroyed, or

From [expr.prim.id.dtor], it seems that only explicitly evaluating 0 .T::~T() destroys the materialized temporary. Where is the implicit destruction that would make this UB specified?

Where is the implicit destruction that would make this UB specified?

That seems to be [class.temporary] p7. So it would seem that GCC and MSVC are non-conforming here.

I think that example cannot prove that 0 .T::~T() causes UB. since [expr.ref#3] is not clear about whether the pseudo-destructor is constexpr

If the object expression is of scalar type, E2 shall name the pseudo-destructor of that same type (ignoring cv-qualifications) and E1.E2 is an lvalue of type “function of () returning void”.

[basic.life#7] has no strong evidence/never that says 0 .T::~T() causes UB since the pseudo-destructor is not non-static member function of scalar type.

Let’s ask @zygoloid since he is the author of the proposal P0593R6.

A few remarks here. First, the comment is certainly wrong, because "no effect" is wrong. We definitely explicitly destroy the 0 temporary here, causing its lifetime to end before the end of the full-expression.

The pseudo-destructor is not a member function, so the question whether it is constexpr doesn't arise (it's handled the way it is by direct core language semantics without involving member functions, even though the syntax looks similar).
Can you point to a provision in [expr.const] that would make invoking a pseudo-destructor non-constexpr? I don't think so.

It seems [basic.life] p7 doesn't speak to the question whether you can end the lifetime of a scalar twice.

http://lists.isocpp.org/core/2021/09/11592.php

For the first point, [expr.call] p5 says

If the postfix-expression names a destructor or pseudo-destructor ([expr.prim.id.dtor]), the type of the function call expression is void;

Hence, 0 .T::~T(); is a function call. As the example mentioned by @JohelEGP

constexpr void f() {
  using T = int;
  (void)0 .T::~T();
}
int main() {
  []() consteval {
    f();
  }();   // #1 shall be a constant expression as per [expr.const] p13
}

An expression E is a core constant expression unless the evaluation of E, following the rules of the abstract machine ([intro.execution]), would evaluate one of the following:

• an invocation of a non-constexpr function;

It is not clear whether the pseudo-destructor is a constexpr function or not, hence it's not clear whether #1 is well-formed or not.

For the second point, it is not clear how to destroy an object of scalar type, whether it behaves as if the corresponding pseudo-constructor is called for that object or behaves something else. At least, [basic.lifetime] didn't say such a case is UB. Incidentally, in [class.dtor] p14, should we consider the destructor of a scalar type as the pseudo-destructor since it didn't restrict type X is class type?

@xmh0511 0 .T::~T() is a function call expression, but there is no function invocation.

@languagelawyer Since it is a function call expression, why is there no function invocation? What's the difference here?

Since it is a function call expression, why is there no function invocation?

Because there is no function to invoke.

What's the difference here?

Function call is an expression of the form «postfix-expression ( expression-list_opt )», function invocation — is transfer of the control flow to a function body. Evaluation of a pseudo-destructor call is described without invocation.

@languagelawyer An function call expression can directly cause a function invocation, an function invocation can be implicitly caused. For the following concept

function invocation — is the transfer of the control flow to a function body. Evaluation of a pseudo-destructor call is described without invocation.

I didn't see an explicit definition in the current standard. Assume it is, however, it's unclear whether a pseudo-destructor has a function body or not. Specifically, [basic.def.odr] p7 designates that it's an odr-use of that function; [basic.def.odr] p10 requires that function shall have a definition.

[basic.def.odr] p7 designates that it's an odr-use of that function; [basic.def.odr] p10 requires that function shall have a definition.

I think it should be just s/name/represent/ in [expr.prim.id.dtor] for pseudo-destructor.

@languagelawyer However, 0 .T::~T is a function, according to [expr.ref] p3

If the object expression is of scalar type, E2 shall name the pseudo-destructor of that same type (ignoring cv-qualifications) and E1.E2 is an lvalue of type “function of () returning void”.

According to [basic.lval] p1

A glvalue is an expression whose evaluation determines the identity of an object or function.

Hence, we could arguably say 0 .T::~T is an lvalue that denotes a function, hence [basic.def.odr] applies here.

Could be solved by introducing the concept of an «empty lvalue» from CWG232. There are other lvalues, in addition to *(T*)0, which can't denote an object.

Actually, I think [expr.ref]/3 should just be prvalue, like in non-scalar type case.

@languagelawyer Agree. I would wonder why is this example not accepted by the implementations

int main() {
   using T = int;
   T a = 0;
   auto ptr = &(a.~T);
}

a.~T is an lvalue, according to [expr.unary.op] p3

The operand of the unary & operator shall be an lvalue of some type T. The result is a prvalue.

• If the operand is a qualified-id naming a non-static or variant member m of some class C, the result has type “pointer to member of class C of type T” and designates C​::​m.
• Otherwise, the result has type “pointer to T” and points to the designated object ([intro.memory]) or function ([basic.compound]).

The example should be fine. It seems that empty value cannot solve the vague of pseudo-destructor since &*(int*)0 is well-formed.

@xmh0511 the example violates https://timsong-cpp.github.io/cppwp/n4868/expr.prim.id.dtor#2.sentence-1

@languagelawyer Ah, right! I forgot that rule. It seems empty value can work here.