<div dir="ltr"><div><div>I agree that the language can pick whatever schedule with whatever degree of parallelism as long as it satisfies the partial order defined 
by data flow and there are no false control dependencies inserted that 
will prevent progress.  The issue is more that adding those variables to the language adds additional ordering requirements based on sequential control flow.  A schedule that satisfies the stricter ordering requirements will satisfy the weaker ones (unless the additional dependencies prevent it from making progress), but the difference in ordering requirements is real.  I don't think it's all that relevant that it's possible for an implementation to exist that satisfies both semantics in many circumstances.  <br><br></div><div>The involvement of foreach is very relevant.  You can unfold a foreach to <iter 1>; <iter 2> <iter 3> under the current semantics.  You can also unfold it to <iter 2>; <iter 1>; <iter 3> and it's the same.  The language needs this to run the iterations out of order based on data availability - there is no problem doing so since the two unfoldings are equivalent.  What's being proposed is that the first unfolding is the canonical one, and you can't do the second one unless you prove that it's equivalent.  So an implementation must guarantee that the loop iterations *don't* execute out of order unless it analyses the loop body sufficiently to prove that there is nothing in there that depends on the sequential order of loop iterations.  But there's another issue.  We would need to provide a strong guarantee that the iterations *do* execute out of order if there is nothing in the loop body to prevent them from doing so, since otherwise the program might fail to make progress when it should, or even deadlock if there is some sort of recursive dependency where the array being iterated over depends directly or indirectly on the computation in the loop body.  So essentially foreach would have to be one of two different control flow constructs (in-order foreach or out-of-order foreach) depending on what you do inside it.<br><br></div><div>That also doesn't address the issue of other array key types.  If you iterate over an array with [auto] keys, what is the canonical order of iterations?<br></div><div><br></div><div>Also,, now that I think about it, presumably negative numbers would go before 0, so if you were iterating over an array with integer keys that had keys [0] to [N] filled in, you couldn't process key [0] until the array was entirely closed.  Seems strange...<br></div><div><br></div><div>I just feel that Swift is fundamentally a language with relaxed ordering.  I don't have anything against a more sequential version for some situations but I feel like it's just a different language.<br><br></div><div>- Tim<br></div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 21, 2015 at 6:06 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov" target="_blank">hategan@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 2015-01-21 at 17:09 -0600, Tim Armstrong wrote:<br>
> Function pointers are probably not a short-term addition - might be simpler<br>
> just to add functions we think are important and have function pointers as<br>
> a longer-term addition.<br>
<br>
</span>I agree. However, comparable in effort to auto-update variables. So<br>
maybe we can decide to not waste effort on one of them.<br>
<span class="HOEnZb"><font color="#888888"><br>
Mihael<br>
<br>
<br>
</font></span></blockquote></div><br></div>