[swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics
clattner at nondot.org
Tue Oct 31 11:48:08 CDT 2017
On Mon, Oct 30, 2017 at 10:55 PM, John McCall <rjmccall at 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution