<div dir="auto">Yeah, I'm not seeing your point here either <span class="gmail_chip gmail_plusreply" dir="auto"><a href="mailto:Alan.Bateman@oracle.com" style="color:#15c;text-decoration:underline">@Alan Bateman</a></span>.<div dir="auto"><br></div><div dir="auto">It almost sounds like you all are saying that, because you don't know which default joiner you are going to use, that you refuse to give us this specific convenience method until you find that default. Maybe the logic behind that train of thought is obvious to you, but not to us. You'll need to explain it. Because in our eyes, the cost is just changing the return type of (and a line of code in) 2 methods -- a cheap thing to do for an API in Preview.</div><div dir="auto"><br></div><div dir="auto">In short, what do you gain by holding off on this until you find the right default? That's not clear to us.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Dec 19, 2025, 6:18 AM Holo The Sage Wolf <<a href="mailto:holo3146@gmail.com">holo3146@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="auto">I don't see how this stops us from adding the overload David suggests.</div><div dir="auto"><br></div><div dir="auto">The current implementation implementation of the 0-args open method is to delegate into the 2-args open method:</div><div dir="auto"><br></div><div dir="auto">... open() {</div><div dir="auto">    return open(<default joiner>, Function.identity());</div><div dir="auto">} </div><div dir="auto"><br></div><div dir="auto">With the suggested overload we will have:</div><div dir="auto"><br></div><div dir="auto">... open() {</div><div dir="auto">    return open(Function.identity())</div><div dir="auto">} </div><div dir="auto"><br></div><div dir="auto">... open(Function<Configuration, Configuration> confFunc) {</div><div dir="auto">    return open(<default joiner>, confFunc);</div><div dir="auto">} </div><div dir="auto"><br></div><div dir="auto">In both cases, changing the default based on users input will mount to changing the joiner in a single place</div><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Fri, 19 Dec 2025, 12:52 Alan Bateman, <<a href="mailto:alan.bateman@oracle.com" rel="noreferrer noreferrer" target="_blank">alan.bateman@oracle.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>

  
  <div>
    <br>
    <br>
    <div>On 19/12/2025 08:33, David Alayachew
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div dir="ltr">
          <div class="gmail_default" style="font-family:monospace">And
            maybe it'll help if I clarify what I was saying to <a class="gmail_plusreply" id="m_368070586224456586m_-6723563698489362921m_-4981193921138808036m_755086139635793918plusReplyChip-7" href="mailto:holo3146@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">@Holo The Sage Wolf</a>.</div>
          <div class="gmail_default" style="font-family:monospace"><br>
          </div>
          <div class="gmail_default" style="font-family:monospace">Holo
            is saying that they like the default joiner, but adding a
            timeout to it takes more code than necessary. They proposed
            multiple different overloads, but I suggested the following
            overload instead.</div>
          <div class="gmail_default" style="font-family:monospace"><br>
          </div>
          <div class="gmail_default" style="font-family:monospace">StructuredTaskScope.open(UnaryOperator<StructuredTaskScope.Configuration>
            configOperator)</div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    There are two built-in joiners that implement the policy to cancel
    the scope and cause join to throw if any subtask fails. One is
    suited to subtasks that produce results of the same type. It can
    collect the results and have join yield the list of results. The
    other is suited to subtasks that produce results of very different
    types and where it is more convenient to retain the Subtask returned
    from fork. The feedback to date on which would be the better default
    is inconclusive. The choice influences the return from the 1-arg
    open method is being discussed here, and is why it is not included
    in the current API.<br>
    <br>
    -Alan<br>
  </div>

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