<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <blockquote type="cite" cite="mid:CAK6PxWMjNJrTp-=N-RQECjcYonstzJBUCUtc7QwOp-FS1CBW=w@mail.gmail.com">
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite">
          <div>
            <div> <br>
              <blockquote type="cite" cite="mid:CAK6PxWMwzGjg0HJ9ym-BnrUDK4Kx6Oj_B355jMqG=GBJ+p1bMg@mail.gmail.com"><br>
                <p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">...
                  but while we're here, the entire of method seems
                  pointless. After all, Processor is, itself, a
                  functional interface, so we can just delete the
                  `StringTemplate.Processor.of()` part of the above
                  snippet and it would exactly the same way!</p>
              </blockquote>
              <br>
              This whole section seems an unnecessary detour, and kind
              of a big distraction.  <br>
            </div>
          </div>
        </blockquote>
        <div class="gmail_quote"><br>
        </div>
        <div class="gmail_quote" dir="ltr">I felt it necessary ...</div>
      </div>
    </blockquote>
    <br>
    Yes, of course by "this is a big distraction", I really meant "let's
    spend a lot more time on it" :)<br>
    <br>
    <blockquote type="cite" cite="mid:CAK6PxWMjNJrTp-=N-RQECjcYonstzJBUCUtc7QwOp-FS1CBW=w@mail.gmail.com">
      <div class="gmail_quote">In that sense, records were very slightly
        non-culture-compatible: <code style="border:1px solid
          rgb(206,206,206);background-color:rgb(244,244,244);padding:0px
          2px;border-radius:2px">LocalDate.getYear()</code> now stands
        out as somewhat weird: </div>
    </blockquote>
    <br>
    Yes, and this was a carefully considered decision.  In the end we
    decided against doubling down on the mistakes of the past, which
    means that some old code now looks, well, old.  That doesn't mean
    we're in a hurry to do this every time, but in the right situations,
    it is a move we can sometimes justify.<br>
    <br>
    <blockquote type="cite" cite="mid:CAK6PxWMjNJrTp-=N-RQECjcYonstzJBUCUtc7QwOp-FS1CBW=w@mail.gmail.com">
      <div class="gmail_quote">In that sense, it is odd that string
        processors have checked-exception-as-a-type-var when <code style="border:1px solid
          rgb(206,206,206);background-color:rgb(244,244,244);padding:0px
          2px;border-radius:2px">j.u.Function</code> interfaces don’t. </div>
    </blockquote>
    <br>
    Sorry, I disagree with this (which is why I tried to prune this
    direction.)  We considered the role of exceptions in Function and
    friends, and we considered the role of exceptions in ST.Processor,
    and because each context was different, we came to different answers
    for different interfaces.  And that's OK!  Because functional
    interfaces were designed to work with or without exceptions.  This
    is not any sort of "glaring inconsistency", just the result of a
    process that requires contextual judgement being applied in
    different contexts.  <br>
    <br>
    <blockquote type="cite" cite="mid:CAK6PxWMjNJrTp-=N-RQECjcYonstzJBUCUtc7QwOp-FS1CBW=w@mail.gmail.com">
      <div class="gmail_quote">Removing it from Processor is the most
        obvious way to tackle that incongruence.</div>
    </blockquote>
    <br>
    IMO this is the kind of "consistency" that certain kinds of
    hobgoblins are attracted to :)<br>
    <br>
    <blockquote type="cite" cite="mid:CAK6PxWMjNJrTp-=N-RQECjcYonstzJBUCUtc7QwOp-FS1CBW=w@mail.gmail.com">
      <div class="gmail_quote"><br>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite">
          <div>
            <div>
              <blockquote type="cite" cite="mid:CAK6PxWMwzGjg0HJ9ym-BnrUDK4Kx6Oj_B355jMqG=GBJ+p1bMg@mail.gmail.com">
                <p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced""><br>
                </p>
                <p style="margin:0px;font-stretch:normal;font-size:12px;line-height:normal;font-family:".AppleSystemUIFontMonospaced"">##
                  Compile time checking</p>
              </blockquote>
              <br>
              Definitely a different topic :)<br>
              <br>
            </div>
          </div>
        </blockquote>
        <br>
      </div>
      <div class="gmail_quote" dir="ltr">The idea that I can type <code style="border:1px solid
          rgb(206,206,206);background-color:rgb(244,244,244);padding:0px
          2px;border-radius:2px">REGEX.”(foo)+bar”</code> and get
        compile-time validation of the regex, and perhaps even
        compile-time construction of a thompson-NFA style tree so that
        the regex loads and runs faster at runtime (shift some of the
        ‘work’ to compile-time) is <i>very</i> exciting, though 😉</div>
    </blockquote>
    <br>
    Yes, it is.  And I understand why it is tempting to want to backdoor
    some of that in through this feature, but this is not how we're
    going to get to a consistent and grounded form of compile-time
    evaluation.  So that will have to wait until we can do it right.<br>
    <br>
    <br>
  </body>
</html>