<div dir="ltr">Correct. That&#39;s why I mentioned primitive types. I believe Float80 and Vec3f are both structures.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 29, 2016 at 4:45 PM, Chris Lattner <span dir="ltr">&lt;<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jan 29, 2016, at 1:41 PM, Trent Nadeau via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="ltr">While true for general arrays in C, you can use memcmp() to compare arrays of primitive types, and that case is the main one for arrays with large numbers of elements (char[], int[], etc.).</div></div></blockquote><div><br></div></span><div>That’s not true in general in C, because some types have undefined padding - Float80 and Vec3f come to mind.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div></font></span><div><div class="h5"><br><blockquote type="cite"><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 29, 2016 at 3:46 PM, Félix Cloutier <span dir="ltr">&lt;<a href="mailto:felixcca@yahoo.ca" target="_blank">felixcca@yahoo.ca</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Regarding ==: to be fair, C doesn&#39;t allow this kind of comparison either, so I don&#39;t think that it will bother a lot of people who need C interop. It is, however, unfortunate for people who want to use it as a first-class Swift construct.</div><div><br></div><div>Regarding the generalized `N x expr` syntax: if we allow it to appear in more places, should we be worried about the fact that x is also a common identifier?</div><div><br></div><div>Also regarding the `N x expr` syntax: how many times should it evaluate `expr`? Once, or N times?</div><div><br></div><div>There seems to be a consensus around allowing subscripts on uniform tuples, regardless of how you actually declare them. However, that part decidedly needs more discussion, so like Joe said earlier, maybe we should spin it off.<span><font color="#888888"><br><div>
<br><span style="font-family:&#39;Lucida Grande&#39;;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">Félix</span>
</div></font></span><div><div>

<br><div><blockquote type="cite"><div>Le 29 janv. 2016 à 14:24:17, Trent Nadeau via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; a écrit :</div><br><div><div dir="ltr" style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">So what if you have a struct containing a 100 element fixed-sized array/tuple? To have that struct conform to Equatable, etc., would you have to explicitly equate the elements?:<div><br></div><div>self.data.0 == other.data.0 &amp;&amp; self.data.1 == other.data.1 &amp;&amp; ...</div><div><br></div><div>Given that large element fixed-sized arrays are common in C, this seems like a huge burden.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 29, 2016 at 2:17 PM, Joe Groff<span> </span><span dir="ltr">&lt;<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>&gt;</span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span><blockquote type="cite"><div>On Jan 29, 2016, at 11:14 AM, Trent Nadeau &lt;<a href="mailto:tanadeau@gmail.com" target="_blank">tanadeau@gmail.com</a>&gt; wrote:</div><br><div><div dir="ltr">Is having fixed arrays with large numbers of elements (256, 1024, etc.) going to cause issues with protocol conformance of tuples? I believe that since the type system doesn&#39;t currently have type-level integers, tuple protocol conformance is done via a hard-coded limit.</div></div></blockquote><div><br></div></span>Tuples still don&#39;t really conform to protocols, we just provide overloads for the &lt;&gt;== operators for small tuples now. Proper language support for tuple protocol conformance ought to account for arbitrary variadic-ness.</div><span><font color="#888888"><div><br></div><div>-Joe</div></font></span><span><div><br><blockquote type="cite"><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 29, 2016 at 1:30 PM, Austin Zheng via swift-evolution<span> </span><span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">That makes sense, thanks. I&#39;m wondering if the N x T syntax might &#39;naturally fall out&#39; of such a system for any other use cases.<br><br>Daydreaming aside, I think this is a great proposal and it&#39;ll make 256-member C array tuples less awful to work with.<br><br>Austin<br><div><div><br>&gt; On Jan 29, 2016, at 10:29 AM, Joe Groff &lt;<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>&gt; wrote:<br>&gt;<br>&gt;<br>&gt;&gt; On Jan 29, 2016, at 10:22 AM, Austin Zheng via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br>&gt;&gt;<br>&gt;&gt; I like the (Count x Type) design, but if Swift got integer generic parameters in the future is this what tuple shorthand syntax would still look like (not rhetorical, actually asking)? It would be nice to future-proof whatever design we come up with, to a reasonable extent.<br>&gt;<br>&gt; You&#39;d still need something to define FixedArray&lt;N&gt; in terms of:<br>&gt;<br>&gt; struct FixedArray&lt;T,N: Int&gt; { var values: (N x T) }<br>&gt;<br>&gt; -Joe<br><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></div></blockquote></div><br><br clear="all"><div><br></div>--<span> </span><br><div>Trent Nadeau</div></div></div></blockquote></div><br></span></div></blockquote></div><br><br clear="all"><div><br></div>--<span> </span><br><div>Trent Nadeau</div></div></div><span style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">_______________________________________________</span><br style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">swift-evolution mailing list</span><br style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:swift-evolution@swift.org" style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">swift-evolution@swift.org</a><br style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:LucidaGrande;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Trent Nadeau</div>
</div>
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div></div><br></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Trent Nadeau</div>
</div>