<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 5 Aug 2020 at 13:35, Marshall Clow <<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div>On Aug 4, 2020, at 4:33 PM, James Skene <<a href="mailto:j.skene@gmail.com" target="_blank">j.skene@gmail.com</a>> wrote:<br><div><blockquote type="cite"><div><div dir="ltr"><div dir="ltr">On Wed, 5 Aug 2020 at 10:18, Marshall Clow <<a href="mailto:mclow.lists@gmail.com" target="_blank">mclow.lists@gmail.com</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On Aug 4, 2020, at 2:41 PM, James Skene <<a href="mailto:j.skene@gmail.com" target="_blank">j.skene@gmail.com</a>> wrote:</div><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>The general templates would be declared as per the spec.  The member functions would be defined something like this:</div></div></div></div></div></div></blockquote><br></div><div>Sure, they *could* be defined something like that.</div><div>But my point is that a conforming implementation need not have `numpunct<char16_t>` at all.</div><div><br></div><div>— Marshall</div><div><br></div></div></blockquote><div><br></div><div>And that comes down to the interpretation of the specification.  Your position, as I understand it, is that the specification does not require the general template to be defined.  </div></div></div></div></blockquote><div><br></div>My position is that if you attempt to instantiate `numpunct<char16_t>`, that is not required to succeed.</div><div><br></div><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_quote"><div>But I don't see the justification for that in the letter of the specification.  And neither is this the position that GCC or Visual Studio take.  So what am I failing to understand?</div></div></div></div></blockquote><br></div><div>What makes you think that the Visual Studio maintainers (or the libtdc++ maintainers) believe that those are required?</div><div><br></div><div>I see that:</div><div>1) The standard requires that some specializations exist.</div><div>2) libstdc++ and Visual Studio provide those, and more.</div><div><br></div><div>They’re allowed to do that.</div><div>That’s different from believing that they are required.</div><div><br></div><div>— Marshall</div><div><br></div></div></blockquote><div><br></div><div>Well, I have already more or less explicitly given three reasons why I think they are required, and they are good enough reasons that I expect the maintainers of VS and libstdc++ probably agree with me:</div><div><br></div><div>1. It looks to me that the standard says they are required (20.5.2.2.1) and nowhere does it say they are not required;</div><div><br></div><div>2. Other implementers provide them;</div><div><br></div><div>3. Implementing them actually *doesn't* require any major effort of implementation or the introduction of platform or locale dependent code into the library, so we can't assume that the standard means for them to be excluded on that basis.</div><div><br></div><div>To this list I will add:</div><div><br></div><div>4. The classes of the locale and Input/Output library are everywhere class templates parameterised by character type, and the possibility of extending support for other character types is explicitly extended to library implementers at least; nor is it explicitly denied to user code, and furthermore the standard library anticipates user extensions, and gives rules for how the standard library can be extended in user code.  But if those two class templates, ctype and numpunct are omitted, then the formatted output operators for std::basic_ostream cannot be reused for char16_t and char32_t (or any other primitive type) by user code, because user code cannot define and add those facets for the different character type to their locale.  User code is explicitly prevented from defining just those facets by the injunction (20.5.4.2.1.1) 'A program may add a template specialization for any standard library template to namespace std only if the declaration depends on a user-defined type and the specialization meets the  library requirements for the original template and is not explicitly prohibited.'  The specialisations std::ctype<char16_t>, std::numpunct<char16_t>, std::ctype<char32_t>, std::numpunct<char32_t> do not depend on any user-defined type and so cannot be defined in user code.  </div><div><br></div><div>So did the designers of the C++ language and standard library, a group which you may count yourself a member of, Marshall, really provide their users with a library that seems extensible, and character types that seem perfect to use to extend it, but with the intent that this should not in fact be done and that nobody should be silly enough to try?  And to make sure that nobody tries, they make the effort impossible due to a technicality involving two obscure aspects of the localisation library, and don't even even bother to include a note to that effect in the specification?</div><div><br></div><div>Also, leaving aside the question of whether excluding these templates is an error, you should want to include them anyway because doing so significantly improves the utility of your implementation.  Under GNU and VS the following works:</div><div><br></div><div>std::basic_stringstream<char16_t> s;</div><div>s << u"Hello world";</div><div><br></div><div>The same code fails to compile with libc++ because 'Implicit instantiation of undefined template 'std::__1::ctype<char16_t>'.  Note that neither the VS or GNU implementations depend on any explicitly specialised templates or char16_t-specific code to make the above work, so they are not actually providing anything beyond the specification - at least if you believe, as I do, that the base template of ctype should be included in the implementation.</div><div><br></div><div>So putting to one side the state of *my* knowledge, what do *you* know that convinces you that all these reasons are wrong and these templates are not required?</div><div><br></div><div>Cheers,</div><div>James</div><div><br></div></div></div></div>