<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 14, 2019, 3:37 PM Tom Honermann &lt;<a href="mailto:tom@honermann.net">tom@honermann.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div class="m_-7765491892077975640moz-cite-prefix">On 8/14/19 5:00 AM, Corentin wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="auto">
        <div><br>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">On Wed, Aug 14, 2019, 4:17
              AM Tom Honermann via Core &lt;<a href="mailto:core@lists.isocpp.org" target="_blank" rel="noreferrer">core@lists.isocpp.org</a>&gt;
              wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Niall,
              this is again off topic for this thread.  But now that you
              put <br>
              this out there, I feel obligated to respond.  But please
              start a new <br>
              thread with a different set of mailing lists if you wish
              to continue <br>
              this any further; this is not a CWG issue.<br>
              <br>
              On 8/13/19 12:03 PM, Niall Douglas via Liaison wrote:<br>
              &gt; On 13/08/2019 15:27, Herring, Davis via Core wrote:<br>
              &gt;&gt;&gt; Is it politically feasible for C++ 23 and C
              2x to require<br>
              &gt;&gt;&gt; implementations to default to interpreting
              source files as either (i) 7<br>
              &gt;&gt;&gt; bit ASCII or (ii) UTF-8? To be specific, char
              literals would thus be<br>
              &gt;&gt;&gt; either 7 bit ASCII or UTF-8.<br>
              &gt;&gt; We could specify the source file directly as a
              sequence of ISO 10646 abstract characters, or even as a
              sequence of UTF-8 code units, but the implementation could
              choose to interpret the disk file to contain KOI-7 N1 with
              some sort of escape sequences for other characters.  You
              might say &quot;That&#39;s not UTF-8 on disk!&quot;, to which the
              implementation replies &quot;That&#39;s how my operating system
              natively stores UTF-8.&quot; and the standard replies &quot;What&#39;s a
              disk?&quot;.<br>
              &gt; I think that&#39;s an unproductive way of looking at the
              situation.<br>
              &gt;<br>
              &gt; I&#39;d prefer to look at it this way:<br>
              &gt;<br>
              &gt;<br>
              &gt; 1. How much existing code gets broken if when
              recompiled as C++ 23, the<br>
              &gt; default is now to assume UTF-8 input unless input is
              obviously not that?<br>
              *All* code built on non-ASCII platforms, some amount of
              code (primarily <br>
              in regions outside the US) that is currently built with
              the Microsoft <br>
              compiler and encoded according to the Windows Active Code
              Page for that <br>
              region, and source code encoded in Shift-JIS or GB18030.<br>
              &gt;<br>
              &gt; (My guess: a fair bit of older code will break, but
              almost all of it<br>
              &gt; will never be compiled as C++ 23)<br>
              <br>
              I think you&#39;ll need to find a way to measure the breakage
              if you want to <br>
              pursue such a change.<br>
              <br>
              Personally, I don&#39;t think this is the right approach as
              adding more <br>
              assumptions about encodings seems likely to lead to even
              more problems.  <br>
              My preference is to focus on explicit solutions like
              adding an encoding <br>
              pragma similarly to what is done in Python and HTML and is
              existing <br>
              practice for IBM&#39;s xlC compiler <br>
              (<a href="https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbclx01/zos_pragma_filetag.htm" rel="noreferrer noreferrer noreferrer" target="_blank">https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.3.0/com.ibm.zos.v2r3.cbclx01/zos_pragma_filetag.htm</a>).<br>
            </blockquote>
          </div>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Except all cross platform (windows, Linux, Mac)
          code ever written - which includes all of GitHub, etc, would
          use ASCII or utf8 already.</div>
        <div dir="auto">Most internal code would avoid non basic
          character set characters already. Because they know it&#39;s not
          portable</div>
      </div>
    </blockquote>
    I lack confidence that this is true, so citation needed please.  I
    know that Shift-JIS (for example) is still in use and we hear that
    from Microsoft representatives.  Regardless, I think it is a mistake
    to assume that cross-platform code is more important than code that
    is written for specific platforms.<br>
    <blockquote type="cite">
      <div dir="auto">
        <div dir="auto"><br>
        </div>
        <div dir="auto">So while I find the idea of pragma interesting,
          I question whether it is the right default. I do not want to
          have to do that to 100% of the I have or will ever write.</div>
      </div>
    </blockquote>
    <p>It would certainly be the wrong default if we were doing a clean
      room design.  But we are evolving a language that has been around
      for several decades and that inherits from a language that was
      around for considerably longer.</p>
    <blockquote type="cite">
      <div dir="auto">
        <div dir="auto"><br>
        </div>
        <div dir="auto">It doesn&#39;t mean a pragma is not helpful for
          people working on an old code base so they can transition away
          from codepage encoding if they are ie, a windows shop only. I
          think it would very much be.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">I think it would also be useful to encourage
          utf8 by default even if that would have no impact whatsoever
          on existing toolchains.</div>
      </div>
    </blockquote>
    I agree. I strongly think the right approach is:
    <ol>
      <li>Keep source file encoding implementation defined.</li>
      <li>Introduce the pragma option to explicitly specify
        per-source-file encoding.</li>
      <li>Encourage implementors to provide options to default the
        assumed source file encoding to UTF-8 (in practice, most already
        provide this)</li>
      <li>Encourage projects to pass /source-file-encoding-is-utf-8
        (however spelled) to their compiler invocations.</li>
    </ol>
    <p>That approach approximates the &quot;right&quot; default fairly closely if
      (4) is followed (which may be an existing trend).</p></div></blockquote></div></div><div dir="auto">That would work.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <blockquote type="cite">
      <div dir="auto">
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">But at the same time it seems it would be
          beneficial to restrict the set of features that require
          Unicode to be limited to Unicode source files, including
          literals and identifiers outside of the basic character sets. </div>
        <div dir="auto">The intent is that making a program ill-formed
          (ndr) encourages a warning which I really want to have when
          the compiler is not interpreting my utf-8 source as utf-8.</div>
      </div>
    </blockquote>
    I strongly disagree with this.  I think you are conflating two
    distinct things (source file encoding and support for Unicode) as a
    proxy to get a diagnostic that, in practice, would not be reliable.<br></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">I am not. Of all the things that it might be beneficial to have implementation defined behavior for, how identifiers and text is handle by compilers is not one of them. I know we disagree on that. But it will be hard to convince me that predicable compiler behavior is not in this instance valuable.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <blockquote type="cite">
      <div dir="auto">
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">You could argue that people on windows </div>
        <div dir="auto">can just compile with /source-charset: utf-8,
          which yes they can and should (it&#39;s standard practice in Qt,
          vcpkg, etc), but avoid potentially lossy encoding due to wrong
          presumption of how a text file was encoded would help people
          write portable code with the assurance that the compiler would
          not miss interpret their intent silently.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">I agree with you that reinterpreting all
          existing code overnight as utf-8 would hinder the adoption of
          future c++ version enough that we should probably avoid to do
          that, but maybe a slight encouragement to use utf8 would be
          beneficial to everyone.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">I agree with Niall, people in NA/Europe
          underestimate the extent of the issue with source encoding.</div>
      </div>
    </blockquote>
    <p>I agree with this.  But I think there is a reverse
      underestimation as well - that being the extent to which people
      outside English speaking regions use non-UTF-8 encodings. 
      IBM/Windows code pages and the ISO-8859 series of character sets
      have a long history.  I think there is good reason to believe they
      are still in use, particularly in older code bases.<br></p></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Generalisation: No C++ developer has the tool to internationalize their software. And all of iso encoding combined are still a very small subset of used characters compared to Unicode.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><p>
    </p>
    <p>Tom.<br>
    </p>
    <blockquote type="cite">
      <div dir="auto">
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">
          <div class="gmail_quote">
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <br>
              &gt;<br>
              &gt;<br>
              &gt; 2. How much do we care if code containing non-UTF8
              high bit characters<br>
              &gt; in its string literals breaks when the compiler
              language version is set<br>
              &gt; to C++ 23 or higher?<br>
              &gt;<br>
              &gt; (My opinion: people using non-ASCII in string
              literals without an<br>
              &gt; accompanying unit test to verify the compiler is
              doing what you assumed<br>
              &gt; deserve to experience breakage)<br>
              <br>
              Instead of non-ASCII, I think you mean characters outside
              the basic <br>
              source character set.<br>
              <br>
              Testing practices have varied widely over time and across
              projects.  I <br>
              don&#39;t think it is acceptable to think it ok for other
              people&#39;s code to <br>
              break because it wasn&#39;t developed to your standards.<br>
              <br>
              &gt;<br>
              &gt;<br>
              &gt; 3. What is the benefit to the ecosystem if the
              committee standardises<br>
              &gt; Unicode source files moving forwards?<br>
              &gt;<br>
              &gt; (My opinion: people consistently underestimate the
              benefit if they live<br>
              &gt; in North America and work only with North American
              source code. I&#39;ve had<br>
              &gt; contracts in the past where a full six weeks of my
              life went on<br>
              &gt; attempting mostly lossless up-conversions from
              multiple legacy encoded<br>
              &gt; source files into UTF-8 source files. Consider that
              most, but not all,<br>
              &gt; use of high bit characters in string literals is
              typically for testing<br>
              &gt; that i18n code works right in various borked
              character encodings, so<br>
              &gt; yes, fun few weeks. And by the way, there is an
              *amazing* Python module<br>
              &gt; full of machine learning heuristics for lossless
              upconverting legacy<br>
              &gt; encodings to UTF-8, it saved me a ton of work)<br>
              I agree we need to provide better means for handling
              source file <br>
              encodings.  But this all-or-nothing approach strikes me as
              very costly.  <br>
              Many applications are composed from multiple projects.
              Improving support <br>
              for UTF-8 encoded source files will require means to adopt
              them <br>
              gradually.  That means that there will be scenarios where
              a single TU is <br>
              built from differently encoded source files. We need a
              more fine grained <br>
              solution.<br>
              &gt;<br>
              &gt;<br>
              &gt; But all the above said:<br>
              &gt;<br>
              &gt; 4. Is this a productive use of committee time, when
              it would displace<br>
              &gt; other items?<br>
              &gt;<br>
              &gt; (My opinion: No, probably not, we have much more
              important stuff before<br>
              &gt; WG21 for C++ 23. However I wouldn&#39;t say the same for
              WG14, personally, I<br>
              &gt; think there is a much bigger bang for the buck over
              there. Hence I ask<br>
              &gt; here for objections, if none, I&#39;ll ask WG14 what they
              think of the idea)<br>
              <br>
              I think this is a productive use of SG16&#39;s time.  I don&#39;t
              think it is a <br>
              productive use of the rest of the committee&#39;s time until
              we have a <br>
              proposal to offer.<br>
              <br>
              Tom.<br>
              <br>
              &gt;<br>
              &gt;<br>
              &gt; Niall<br>
              &gt; _______________________________________________<br>
              &gt; Liaison mailing list<br>
              &gt; <a href="mailto:Liaison@lists.isocpp.org" rel="noreferrer noreferrer" target="_blank">Liaison@lists.isocpp.org</a><br>
              &gt; Subscription: <a href="https://lists.isocpp.org/mailman/listinfo.cgi/liaison" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.isocpp.org/mailman/listinfo.cgi/liaison</a><br>
              &gt; Link to this post: <a href="http://lists.isocpp.org/liaison/2019/08/0009.php" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.isocpp.org/liaison/2019/08/0009.php</a><br>
              <br>
              <br>
              _______________________________________________<br>
              Core mailing list<br>
              <a href="mailto:Core@lists.isocpp.org" rel="noreferrer noreferrer" target="_blank">Core@lists.isocpp.org</a><br>
              Subscription: <a href="https://lists.isocpp.org/mailman/listinfo.cgi/core" rel="noreferrer noreferrer noreferrer" target="_blank">https://lists.isocpp.org/mailman/listinfo.cgi/core</a><br>
              Link to this post: <a href="http://lists.isocpp.org/core/2019/08/7045.php" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.isocpp.org/core/2019/08/7045.php</a><br>
            </blockquote>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
  </div>

</blockquote></div></div></div>