<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Thanks everyone.<br>
    <br>
    I'll report back what Core decides for the Reflection TS.<br>
    <br>
    Axel.<br>
    <br>
    <div class="moz-cite-prefix">On 18.02.19 08:17, Robert Douglas
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAEGt33v2EQLADo2-ScVbdHb=hhqLO2CBjqjMiLY1U9BXBfnOPg@mail.gmail.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">
          <div dir="ltr">Historical footnote, these are intended to be
            as drop-in as possible for existing facilities. __FILE__ is
            a "character string literal," which gets it's null
            termination in phase 7. Since we are accessing these at
            run-time, we should thus expect these to be NTBS. Changes to
            this expectation would be a deviation from these being a
            drop-in replacement to __FILE__ and __func__. Note that
            [dcl.fct.def.general]<br>
          </div>
          <div> p 8 defines __func__ as an implementation-defined string
            as if <span style="font-family:monospace,monospace">static
              const char __func__[] = "function-name ";</span> which
            implies, also, an NTBS. This is the reasoning for NTBS. To
            do otherwise, would deviate this feature from __FILE__ and
            __func__, which it is designed to replace.<br>
            <br>
          </div>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Mon, Feb 18, 2019 at 11:20
          AM Corentin &lt;<a href="mailto:corentin.jabot@gmail.com"
            moz-do-not-send="true">corentin.jabot@gmail.com</a>&gt;
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Quick
          reply : display only, no expectation the file can be open, or
          exists, or is a file. It's purely informative. But expectation
          it can be displayed, the main use cases being logging.
          Otherwise I agree with you.<br>
          <br>
          <div class="gmail_quote">
            <div dir="ltr">On Mon, Feb 18, 2019, 7:16 AM Tom Honermann
              &lt;<a href="mailto:tom@honermann.net" target="_blank"
                moz-do-not-send="true">tom@honermann.net</a>&gt; wrote:<br>
            </div>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div dir="auto"><br>
                <div dir="ltr">On Feb 18, 2019, at 10:04 AM, Corentin
                  &lt;<a href="mailto:corentin.jabot@gmail.com"
                    target="_blank" moz-do-not-send="true">corentin.jabot@gmail.com</a>&gt;
                  wrote:<br>
                  <br>
                </div>
                <blockquote type="cite">
                  <div dir="ltr">
                    <div dir="ltr"><br>
                      <div>Very good points. </div>
                      <div>Wouldn't it be sufficient to specify that the
                        strings are NTMBS encoded using the execution
                        character set?</div>
                    </div>
                  </div>
                </blockquote>
                <blockquote type="cite">
                  <div dir="ltr">
                    <div dir="ltr">
                      <div>source_location currently avoids making any
                        assumption about how these strings are formed,
                        including that they are derived from a source
                        file.</div>
                      <div>So since the value is implementation-defined,
                        so should be the way it's constructed. </div>
                      <div>However, it is reasonable to assume that
                        these things are valid text and therefore have a
                        known encoding.</div>
                      <div><br>
                      </div>
                      <div>Adding Tom, because this is borderline SG16
                        territory. </div>
                    </div>
                  </div>
                </blockquote>
                <div><br>
                </div>
                <div>This isn’t borderline as we have (recently)
                  requested review of anything involving file names. </div>
                <br>
                <blockquote type="cite">
                  <div dir="ltr">
                    <div dir="ltr">
                      <div><br>
                      </div>
                      <div><br>
                      </div>
                      <div>@Tom: Do you want to see source_location this
                        week knowing that I'd hope it would get through
                        LWG before the end of the week?</div>
                      <div>Or do you think having function_name /
                        filename as multi-bytes strings encoded using
                        the execution character set is reasonable?</div>
                      <div>The alternative I see are</div>
                      <div>
                        <ul>
                          <li><font size="2">Leave it unspecified</font></li>
                          <li><font size="2">Force a specific character
                              set... which the world is not ready for</font></li>
                        </ul>
                      </div>
                    </div>
                  </div>
                </blockquote>
                <div>I think there is a higher level question to answer.
                  Are the provided file names display only, or should
                  one expect to be able to open the file using the
                  provided name?</div>
                <div><br>
                </div>
                <div>If they are display only, then we can specify an
                  encoding for them similarly to what is done for member
                  functions of std::filesystem::path. In this case, we
                  must explicitly acknowledge that the names do not
                  roundtrip through the filesystem (though typically
                  will in practice). Note that, on <span
                    style="background-color:rgba(255,255,255,0)">Windows,
                    file names cannot be represented accurately using
                    char based strings, so unless we want to add wchar_t
                    support, these names will be technically display
                    only. </span></div>
                <div><br>
                </div>
                If they are potentially not display only, then we can’t
                associate an encoding and the names are bags-of-bytes.
                This is a limitation of POSIX. But then we need wchar_t
                support for Windows. 
                <div><br>
                </div>
                <div>In San Diego, the guidance we gave for the
                  stacktrace proposal is that file names are
                   implementation defined <span
                    style="background-color:rgba(255,255,255,0)">bags-of-bytes.
                    If we advised otherwise for source location, we
                    would be giving inconsistent guidance. </span></div>
                <div><br>
                </div>
                <div>I think we should discuss this in SG16 this week.
                  Not necessarily to propose changes for the proposal,
                  but to solidify our collective thinking around file
                  names. </div>
              </div>
              <div dir="auto">
                <div><br>
                </div>
                <div>Tom. <br>
                  <div>
                    <blockquote type="cite">
                      <div dir="ltr">
                        <div dir="ltr">
                          <div><br>
                          </div>
                          <div>Thanks, </div>
                          <div>Corentin</div>
                          <div><br>
                          </div>
                          <div><br>
                          </div>
                          <br>
                          <div class="gmail_quote">
                            <div dir="ltr" class="gmail_attr">On Mon, 18
                              Feb 2019 at 03:56 Axel Naumann &lt;<a
                                href="mailto:Axel.Naumann@cern.ch"
                                target="_blank" moz-do-not-send="true">Axel.Naumann@cern.ch</a>&gt;
                              wrote:<br>
                            </div>
                            <blockquote class="gmail_quote"
                              style="margin:0px 0px 0px
                              0.8ex;border-left:1px solid
                              rgb(204,204,204);padding-left:1ex">Hi
                              Robert,<br>
                              <br>
                              Regarding your P1208R3:<br>
                              <br>
                              Nit: it's titled "D1208R3", it doesn't
                              mention email addresses.<br>
                              <br>
                              Not-so-nit: a NB comment on the reflection
                              TS asks to not use NTBS but<br>
                              NTMBS and "Where NTBS is mentioned in the
                              document under ballot, the<br>
                              encoding used for the string’s value is
                              unspecified." Jens agrees that<br>
                              the proposed solution should be applied:
                              "Specify that the strings are<br>
                              first formed using the basic source
                              character set (with<br>
                              universal-character-names as necessary)
                              then mapped in the manner<br>
                              applied to string literals with no
                              encoding prefix in phases 5 and 6 of<br>
                              translation."<br>
                              <br>
                              I would very much hope that both changes
                              are also applied to P1208R3. I<br>
                              call this out explicitly in our
                              recommended NB comment response paper.<br>
                              <br>
                              Cheers, Axel.<br>
                            </blockquote>
                          </div>
                        </div>
                      </div>
                    </blockquote>
                  </div>
                </div>
              </div>
            </blockquote>
          </div>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>