[swift-evolution] [Discussion] Swift for Data Science / ML / Big Data analytics

[Chris Lattner]

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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171031/b337d1b2/attachment.html>