<html><head></head><body dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div class="AppleOriginalContents" style="direction: ltr;"><blockquote type="cite"><div>On May 29, 2017, at 5:39 PM, Nicolas Fezans via swift-evolution &lt;swift-evolution@swift.org&gt; wrote:</div><br class="Apple-interchange-newline"><div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class="gmail_quote"><div class=""><br class="Apple-interchange-newline">On Mon 29. May 2017 at 20:57, David Sweeris via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">&gt; On May 29, 2017, at 01:12, Tino Heth via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt; wrote:<br class="">&gt;<br class="">&gt; I agree strongly that the syntax looks awkward — imho<br class="">&gt; var v: Vector&lt;Int, size: 3&gt;<br class="">&gt; would be a much better fit than<br class="">&gt; var v array 3 of Int<br class="">&gt;<br class="">&gt; As much as I want to have "real" arrays, I don't think we should add new keywords for them.<br class=""></blockquote></div></div></div></div></blockquote><div class="AppleOriginalContents" style="direction: ltr;"><br></div><div class="AppleOriginalContents" style="direction: ltr;">Should Swift be closed to adding any new keywords, beside those that start with “#”? Or is it just not using a keyword for static-sized arrays? If yes for that last question, are you proposing that nominal arrays be dropped, since “array” is still needed as a tag to introduce them?</div><div class="AppleOriginalContents" style="direction: ltr;"><br></div><blockquote type="cite"><div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;">Yeah, a "fixed-size array" is probably the most obvious use-case for allowing literal values to be generic parameters. In fact, at that point, they'd just be another type... no special support needed, other than validating the count when assigning array literals to them.</blockquote></div></div></div></div></blockquote><div class="AppleOriginalContents" style="direction: ltr;"><br></div><div class="AppleOriginalContents" style="direction: ltr;">Still need some sort of special support. There either needs to be a directive inside the struct to create a contiguous block of objects, or your static-sized array generic struct needs to be a straight-up magical type. When I first had a similar idea, I had to consider how a directive would interact with other stored properties, or would I block said interactions. At that point, what’s the difference between a struct with a bunch of tweaks and a new category of type. We didn’t make enum a struct with funny settings, after all.</div><div class="AppleOriginalContents" style="direction: ltr;"><br></div><blockquote type="cite"><div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><br class="">The syntax that gained some traction last time they were seriously discussed would also be better, IMHO:<br class="">let x: [Int x 4]<br class="">or maybe it was this?<br class="">let x: [Int * 4]<br class="">Either way, it's more concise, far easier to read (IMHO), and doesn't need new keyword(s).</blockquote><div class=""><br class=""></div><div class="">I have not followed all previous discussions on this (so sorry if it was already proposed and/or discussed) but from the point of view of the "standard mathematics writing", it seems to me that it should rather be [Int^4] .</div></div></div></div></div></blockquote><div class="AppleOriginalContents" style="direction: ltr;"><br></div><div class="AppleOriginalContents" style="direction: ltr;">C++ has its set of punctuators fixed by the language. Swift doesn’t do this; its punctuators are mostly user level, just like identifiers. And just like identifiers, there are a small set of punctuators reserved for the language itself, an analogue of keywords. Using “x”, “*”, or “^” would take some string out of free use and into (conditional) reserved use. Since I’m already using “array” as a tag for nominal arrays, why not reuse the word for immediate arrays.</div><div class="AppleOriginalContents" style="direction: ltr;"><br></div><blockquote type="cite"><div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class="gmail_quote"><div class="">Indeed the three dimensional space built by combining the set of real numbers R is noted R^3 or alternatively RxRxR (but for larger dimensions you certainly do not want this writing!)</div><div class=""><br class=""></div><div class="">Strictly speaking &nbsp;Int^4 &nbsp;would be mathematically speaking more correct but &nbsp;[Int^4] &nbsp;has the advantage of making clear that this is indeed an array.</div></div></div></div></div></blockquote><div class="AppleOriginalContents" style="direction: ltr;"><br></div><div class="AppleOriginalContents" style="direction: ltr;">If this change like this is made, what about “[N for Int]” for immediate arrays and “[for Int]” for array-segment references? The count goes first so nested arrays keep their extent priority order the same as C’s nested arrays. (Otherwise, the C to Swift source-code converter would have to flip the order of the extents.) Using “of” for the separator would be better, but that would violate the desire to avoid new keywords. Of course, how would nominal arrays be declared under this design? Or would those be dropped?</div><div class="AppleOriginalContents" style="direction: ltr;"><br></div><blockquote type="cite"><div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class="gmail_quote"><div class="">There are many aspects in the initial proposal that certainly need a more expert eye than mine. I have one question though. It seems to me that the constant expressions as known as constexpr in C++11 would be allowed as well. Is that right? If yes, are there any differences in the proposal to what is allowed in C++11?&nbsp;</div></div></div></div></div></blockquote></div><br><div>—&nbsp;</div><div><div id="AppleMailSignature"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Daryle Walker<br>Mac, Internet, and Video Game Junkie<br>darylew AT mac DOT com&nbsp;</div><div><br></div></div></div></div></body></html>