<div dir="ltr">Thank you Chris, James.<div><br></div><div>I&#39;m answering James feedback/questions below.<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 4, 2016 at 1:57 AM James Froggatt &lt;<a href="mailto:james.froggatt@me.com">james.froggatt@me.com</a>&gt; wrote:</div><div dir="ltr"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>What are your thoughts on using tuples for this? </div><div><br></div><div>typealias CGPoint4 = (CGPoint, <span style="background-color:rgba(255,255,255,0)">CGPoint, CGPoint, CGPoint)</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">struct Quad { var corners: CGPoint4 }</span></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><div><span style="background-color:rgba(255,255,255,0)">var fixedLength = (point1, point2, point3, point4)</span></div><div><span style="background-color:rgba(255,255,255,0)">print(fixedLength.0)</span></div><div><span style="background-color:rgba(255,255,255,0)">print(fixedLength.4) //compiler error, not an element of the tuple</span></div></div><div><span style="background-color:rgba(255,255,255,0)"><br></span></div><div><span style="background-color:rgba(255,255,255,0)">With shorthand declaration syntax, this would have the benefits of a fixed-length array with added compile-time safety. A previously suggested syntax was along the lines of &#39;(CGPoint * 4)&#39;.</span></div></div><div dir="auto"><br></div></blockquote><div><br></div><div>I investigated tuples a bit, it&#39;s close. The one thing I&#39;d need is being able to index the values using a variable. The tuple.i notation apparently doesn&#39;t work (or I did not try hard enough). Also, for low-level things that will be mapped to GPU memory, precise/predictable/settable alignment is needed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><blockquote type="cite"><div><div dir="ltr"><div>4. Reference/pointer to structs: accessing &amp; modifying structs deep into the model currently requires fully qualified path to the struct instance. Fully qualifying an inner struct in your data model can be very tedious, depending on model complexity. </div><div> </div><div>For instance, with scoped access solutions made with Swift 3, you need to cascade blocks if you need to access multiple inner structs, which doesn&#39;t scale well as it creates code pyramids:</div><div><br></div><div>scopedAccess(&amp;varA) {  </div><div>     scopedAccess(&amp;varB) {  </div><div>          // modify varA &amp; varB  </div><div>     }  </div><div>}</div><div>  </div><div>It&#39;s easily done in C/C++ using pointers/references. To make that better, we&#39;d need some kind of language support IMO.</div></div></div></blockquote><div><br></div></div><div dir="auto"><div>Could this be generalised, maybe with a reference-semantic ‘property accessor’?</div><div><br></div><div>Example:</div><div><br></div><div>let get: () -&gt; Bool = #get(controller.view.isVisible)</div><div>print(get())</div><div><br></div><div>let set: (Bool) -&gt; () = #set(controller.view.isVisible)</div><div>set(true)</div><div><br></div><div>let accessor: Lens&lt;Bool&gt; = #lens(controller.view.isVisible)</div><div>print(accessor.value)</div><div>accessor.value = true</div><div><br></div><div>This would have the added bonus of also tracking the reassignment of reference-type properties - in this example, if &#39;view&#39; is reassigned, the referenced value is updated.</div></div></blockquote><div><br></div><div>Sounds good, I&#39;m not aware of this syntax. Will investigate, thanks.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br><blockquote type="cite"><div><div dir="ltr"><div>5. Memory / pointer access, including casting. It&#39;s too verbose currently IMO when compared to C. Should be better supported for a language that is also targeting low-level (network, disk storage). A syntax that is both fast (like C) and safe would be great.</div></div></div></blockquote><div><br></div></div><div dir="auto"><div>Not familiar with low-level programming in Swift, but have you considered creating domain-specific operators?</div><div>For example, I imagine something like &#39;UnsafeMutablePointer(v)&#39; could be reduced to &#39;*v&#39;.</div></div><div dir="auto"><div><br></div></div></blockquote><div><br></div><div>Do you mean operator is available only within a limited scope? That would be interesting, because I don&#39;t want to pollute global scope with such all-purpose operator. Sounds that I need to investigate that as well.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><br><blockquote type="cite"><div><div dir="ltr"><div>7. I&#39;m also fan of async/await kind of stuff, asynchronous flows, etc., but this has already been mentioned -&gt; cool!</div></div></div></blockquote><div><br></div></div><div dir="auto"><div>I would like to see some ideas in this area.</div><div>async/await never really clicked for me until I realised it&#39;s just syntactic sugar - &#39;await&#39; actually ends the function, and everything below is an implicit callback. Personally I feel like Swift&#39;s trailing closure syntax makes callbacks lightweight enough that this isn&#39;t so much of an issue. Something focusing more on the memory-management and thread-safety aspects of asynchronous code does seem useful in the context of Swift.</div></div><div dir="auto"></div><div dir="auto"><blockquote type="cite"><div><br></div></blockquote></div></blockquote><div>Sure thread-safety, atomicity features would be really nice &amp; useful. </div><div><br></div><div>The one problem I have with closure syntax (trailing or not, I like trailing too), is that when you chain a few of them, which is pretty frequent is async programming, you end up with a closure pyramid. It doesn&#39;t scale well beyond 2 or 3 levels.</div><div> </div><div>Raphael</div></div></div></div>