UB wording in §12.6.2/16

[Arcoth]

Member functions (including virtual member functions, 10.3) can be called for an object under construction. Similarly, an object under construction can be the operand of the typeid operator (5.2.8) or of a dynamic_cast (5.2.7). However, if these operations are performed in a ctor-initializer (or in a function called directly or indirectly from a ctor-initializer) before all the _mem-initializer_s for base classes have completed, the result of the operation is undefined.

That's assuredly meant to read "the behavior is undefined".

[sigfpe]

Agreed.-------- Original message --------From: Arcoth notifications@github.com Date: 10/29/2015 11:26 AM (GMT-08:00) To: cplusplus/draft draft@noreply.github.com Subject: [draft] UB wording in §12.6.2/16 (#557)

[…], the result of the operation is undefined.

That's assuredly meant to read "the behavior is undefined".

—
Reply to this email directly or view it on GitHub.

[Arcoth]

Actually, the "result of … is undefined" is also used in §12.7/5:

If the operand of typeid refers to the object under construction or destruction and the static type of the operand is neither the constructor or destructor’s class nor one of its bases, the result of typeid is undefined.

Then again, the same situation for dynamic_cast causes undefined behavior as per the next paragraph. In the first quote, it appears that for typeid the result is undefined, while calling a function or performing dynamic_casts should have undefined behavior.

[Arcoth]

… and of course the example in p6 isn't consistent with the wording:

typeid(*a); // undefined behavior: type A not a base of B

Presumably all occurrences of "result of … is undefined" should be replaced with "behavior is undefined", since that's what it's supposed to mean?