On Mon, Oct 30, 2017 at 10:55 PM, John McCall <rjmcc...@apple.com> wrote:
> > I can think of two things that could tip the scale of the discussion: > > 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. > > b) The ownership proposal is likely to add deinit'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? > > > I was hoping not to have to add explicit move/copy initializers, perhaps > ever. > Can you elaborate more on why? I'm even more interested in your the rationale more than the outcome :-) I would suggest one of two things: > - We could add a Builtin type for these types in Swift. Because of our > architecture, this is mostly an IRGen task. > Yes, this could definitely work. > - We could start working on C++ import. C++ import is a huge task, but > we don't really need most of it for this. > 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'd prefer going the direction of suggestion #1 above and allowing a "pure swift and explicitly unsafe" solution. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution