Maybe I missed something, but from the discussion I'm not quite clear about what the use case is.<br><br>It seems like there are three possibilities for the data structure:<br><br>1 Order is completely unimportant (i.e. the data structure is a set or multi-set)<br>
2 Relative order is important (i.e. if the assignment happens in a later iteration of a for loop, it should be later in the list)<br>3 Absolute order is important - i.e. we're using explicit array indices<br><br>It seems like you're proposing 2, which seems a bit odd to me in the context of swift as it adds some kind of sequential dependency between iterations of a for loop when determining array indices.<br>
<br>The idea of building a nested (ragged) array and then flattening it seems more swift-like to me.<br><br>Ie. <br>
  foreach i in a {<br>
    foreach j in b {<br>
      output[i][j] = f(i,j)<br>
    }<br>
  }<br>file output2[];<br>
output2 = flatten(output)<br><br>That is kind of clunky though.  Would it be possible to have some kind of syntax for implicitly flattening arrays, e.g.:<br><br>file output2[];<br>foreach i in a {<br>  foreach j in b {<br>
     output[i,j] = f(i,j)<br>  }<br>}<br><br>- Tim<br><br><div class="gmail_quote">On Sat, Jun 18, 2011 at 5:57 PM, Mihael Hategan <span dir="ltr"><<a href="mailto:hategan@mcs.anl.gov">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;"><div class="im">On Sun, 2011-06-19 at 01:36 +0100, Ben Clifford wrote:<br>
> On Jun 19, 2011, at 1:21 AM, Mihael Hategan wrote:<br>
><br>
> > I wasn't discussing an issue of semantics. I think we agree on that. I'm<br>
> > simply saying that I prefer one syntax to the other<br>
><br>
> ok. I'm not overly enthused about the syntax either way.<br>
><br>
> >><br>
> >> I personally find the idea of expression what looks like a mutating<br>
> >> concatenation but isn't really to be more distasteful.<br>
> ><br>
> > Except it is a mutating concatenation. But it's one that is acceptable<br>
> > because there is no way to have code that is nondeterministic because of<br>
> > it. It's a non-destructive mutation.<br>
><br>
> do you regard the 2nd statement in:<br>
><br>
> a[0] = 4343;<br>
> a[1] = 54354;<br>
><br>
> to be mutating?<br>
<br>
</div>Looks like it: a_without_it != a_with_it (where it = second statement),<br>
Though, again, swift doesn't allow you to compare a before with a after.<br>
There is no explicit or implicit notion of time or time sequence.<br>
<div class="im"><br>
>  if so, then a += 54354; is also a mutating concatenation in that<br>
> definition of the word, and I agree with you. Otherwise I disagree<br>
> with you.<br>
<br>
</div>Right. The statement above applies equally well.<br>
<div class="im"><br>
><br>
> But my perspective is that in a swift run, the 'a' array above has a<br>
> single value, described as: "the 0th element is 4343, and the 1st<br>
> element is 4343" and that the value becomes more accurately known as<br>
> the run progresses until such time as you know its value completely.<br>
> In that sense, the 2nd statement above, and the concatenation-like<br>
> operators discussed in this thread are absolutely not mutating: they<br>
> define the final value and that is all. From that perspective, the<br>
> ability to pipeline based on partial knowledge of that value is<br>
> somewhat accidental.<br>
><br>
</div>I agree. Point being that both may look like a mutating operation in<br>
some arbitrary non-swift language, but they are what they are in swift.<br>
So I don't think that a = a + [1] looks more mutating than a[next_index]<br>
= 1. Given that they are equivalent from that perspective, the remaining<br>
deciding factors should be unrelated to this issue.<br>
<div><div></div><div class="h5"><br>
_______________________________________________<br>
Swift-devel mailing list<br>
<a href="mailto:Swift-devel@ci.uchicago.edu">Swift-devel@ci.uchicago.edu</a><br>
<a href="http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel" target="_blank">http://mail.ci.uchicago.edu/mailman/listinfo/swift-devel</a><br>
</div></div></blockquote></div><br>