<div dir="ltr">On Mon, Oct 30, 2017 at 10:55 PM, John McCall <span dir="ltr">&lt;<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>&gt;</span> wrote:<br><div class="gmail_extra"><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"><div style="word-wrap:break-word"><div><div><div class="gmail-h5"><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div><br></div><div>I can think of two things that could tip the scale of the discussion:</div><div><br></div><div>a) The big question is whether we *want* the ability to write custom rule-of-5 style behavior for structs, or if we want it to only be used in extreme cases (like bridging interop in this proposal).  If we *want* to support it someday, then adding proper “safe” support is best (if possible).  If we don’t *want* people to use it, then making it Unsafe and ugly is a reasonable way to go.</div><div><br></div><div>b) The ownership proposal is likely to add deinit&#39;s to structs.  If it also adds explicit move initializers, then it is probably the right thing to add copy initializers also (and thus go with approach #2).  That said,  I’m not sure how the move initializers will be spelled or if that is the likely direction.  If it won’t add these, then it is probably better to go with approach #1.  John, what do you think?</div></div></div></div></blockquote><div><br></div></div></div>I was hoping not to have to add explicit move/copy initializers, perhaps ever.  </div></div></blockquote><div><br></div><div><div class="gmail_extra">Can you elaborate more on why?  I&#39;m even more interested in your the rationale more than the outcome :-)</div></div><div><br></div><div><br></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"><div style="word-wrap:break-word"><div>I would suggest one of two things:</div><div>  - We could add a Builtin type for these types in Swift.  Because of our architecture, this is mostly an IRGen task.</div></div></blockquote><div><br></div><div>Yes, this could definitely work.</div><div> </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"><div style="word-wrap:break-word"><div>  - We could start working on C++ import.  C++ import is a huge task, but we don&#39;t really need most of it for this.</div><span class="gmail-HOEnZb"><font color="#888888"><div></div></font></span></div></blockquote></div><br></div><div class="gmail_extra">This could work, but it would be unfortunate to push people to having to write (unsafe) C++ and import it into Swift to achieve simple things like this.  I&#39;d prefer going the direction of suggestion #1 above and allowing a &quot;pure swift and explicitly unsafe&quot; solution.</div><div class="gmail_extra"><br></div><div class="gmail_extra">-Chris</div><div class="gmail_extra"><br></div></div>