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

> On 28. Oct 2017, at 23:10, Chris Lattner via swift-evolution > wrote: > > … which is to say, exactly identical to the Python version except that new > variables need to be declared with let/var. This can be done by blessing > Python.Object (which is identical to “PyObject*” at the machine l

Re: [swift-evolution] Making capturing semantics of local

On 28 October 2017 at 23:45, Mike Kluev wrote: > on Date: Fri, 27 Oct 2017 15:15:15 -0400 Alex Lynch > wrote: > > I use local functions heavily in my day-to-day workflow and an very >> interested in them supporting capture lists. >> Here is a draft feature specification: >> https://bitbucket.org

Re: [swift-evolution] Making capturing semantics of local

> On 28 Oct 2017, at 10:14 pm, John McCall wrote: > > >> On Oct 28, 2017, at 6:05 AM, Johannes Weiß via swift-evolution >> wrote: >> >> Hi Mike, >> >>> On 27 Oct 2017, at 7:05 pm, Mike Kluev wrote: >>> >>> on Date: Fri, 27 Oct 2017 17:52:54 +0100 Johannes Weiß >>> wrote: >>> On 2

[swift-evolution] classprivate protection level?

i am missing some protection level, which can be called "classprivate" or "structprivate" / "enumprivate" (names could be better). here is an example: --- file Some.swift --- class Some { private func foo() { bar() // error: inaccessible due to 'private' } } --- file Some+Bar.swift --- ext

Re: [swift-evolution] Making capturing semantics of local

On 29 October 2017 at 14:02, Johannes Weiß wrote: Definitely not arguing with that. But there are (valid?) cases when you > want a recursive closure which doesn’t have a native recursion mechanism > and then `fix` can be useful I’d argue. I think more straightforward than > > recursive.c = { x in

Re: [swift-evolution] Making capturing semantics of local

On 28 October 2017 at 00:00, Slava Pestov wrote: > That sounds like a bug, and it could occur with closure expressions also, > since at the SILGen level and below they’re basically the same thing. > > indeed: let closure = {} print("closure is \(closure)") // prints: "closure is (Function)"

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

> On Oct 29, 2017, at 4:04 AM, Lukas Stabe wrote: > >> On 28. Oct 2017, at 23:10, Chris Lattner via swift-evolution >> wrote: >> >> … which is to say, exactly identical to the Python version except that new >> variables need to be declared with let/var. This can be done by blessing >> Pyth

Re: [swift-evolution] classprivate protection level?

Internal is the right choice here. If it gives too much access then you might consider pulling this code into a separate module. If “private” gave access to every extension then any code outside your module could make a new extension and access that method. That would make it effectively public

Re: [swift-evolution] classprivate protection level?

Internal is the best choice available at the moment but I wouldn’t call it the “right” choice. Languages with the concept of classes often have a “protected” scope with means “visible within this class and subclasses”. In Swift that could mean “visible within this class, subclasses, and extensio

Re: [swift-evolution] Making capturing semantics of local

> On 29 Oct 2017, at 3:01 pm, Mike Kluev wrote: > >> On 29 October 2017 at 14:02, Johannes Weiß wrote: >> >> Definitely not arguing with that. But there are (valid?) cases when you want >> a recursive closure which doesn’t have a native recursion mechanism and then >> `fix` can be useful I’

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

A complementary tactic would be that migration tool support to Swift 5 would insert the needed casts to NSString. That way even if the magic lookup is gone in Swift 5 the code could be automatically migrated and preserve the same semantics. If this came to a formal proposal I’d really like to

Re: [swift-evolution] classprivate protection level?

You’re not really missing an other access modifier here. I assume you’re speaking about a macOS/iOS app, right? Therefore the thing you’re really missing is a full integration of SPM in Xcode macOS/iOS projects and submodules. Then, and only then `internal` would really seem like the right choi

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

> On Oct 29, 2017, at 8:23 AM, Chris Lattner via swift-evolution > wrote: > > >> On Oct 29, 2017, at 4:04 AM, Lukas Stabe wrote: >> >>> On 28. Oct 2017, at 23:10, Chris Lattner via swift-evolution >>> wrote: >>> >>> … which is to say, exactly identical to the Python version except that ne

Re: [swift-evolution] SE-0030 Property Behaviors

> On Oct 28, 2017, at 9:00 PM, Andrew Thompson via swift-evolution > wrote: > > Hi Swift Evolution, > > Property Behaviors are a really neat feature and it’s unfortunate that it’s > progress seems to have stopped. > > Located here >

Re: [swift-evolution] [SPM] Roadmap?

I would like to see: - Xcode integration I guess that entails: - Support for iOS - Support for Assets - Better error reporting (SPM’s error messages are often cryptic) - Improve the testing story on Linux (as mentioned elsewhere) -g. ___ swift-ev

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

It would be really nice if Cython code could be linked into iOS and Mac apps written in Swift or Objective-C. http://cython.org -- C. Keith Ray Senior Software Engineer / Trainer / Agile Coach * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf > On Oct 29, 2017, at 1:34 PM, Chr

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

> On Oct 29, 2017, at 3:23 PM, C. Keith Ray wrote: > > It would be really nice if Cython code could be linked into iOS and Mac apps > written in Swift or Objective-C. > > http://cython.org Isn’t that possible today, at least on the Mac? -Chris > > -- > C. Keith Ray > S

Re: [swift-evolution] classprivate protection level?

Even if separating code into modules was an effortless process “internal" would still not be the right access modifier because you would have to make a sub-module for every class in a class hierarchy which defined new “protected” members. So we would need some near-effortless process for creatin

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

There's surprisingly little information about Cython interoperability with Cocoa/Mac applications. It's might be linkable if the app can embed Python. -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf * http://agilesol

Re: [swift-evolution] classprivate protection level?

On 29 October 2017 at 16:04, Adam Kemp wrote: > Internal is the right choice here. If it gives too much access then you > might consider pulling this code into a separate module. > > If “private” gave access to every extension then any code outside your > module could make a new extension and acc

Re: [swift-evolution] classprivate protection level?

> On Oct 29, 2017, at 5:29 PM, Mike Kluev wrote: > >> On 29 October 2017 at 16:04, Adam Kemp wrote: >> Internal is the right choice here. If it gives too much access then you >> might consider pulling this code into a separate module. >> >> If “private” gave access to every extension then an

Re: [swift-evolution] classprivate protection level?

On 30 October 2017 at 02:54, Adam Kemp wrote: > > That was my original point. This is what internal does. We don’t need any > new access levels for extensions. Internal solves these use cases. Code in > the same module can be maintained in lockstep so you can make things > internal as needed for

Re: [swift-evolution] classprivate protection level?

Access levels exist for encapsulation. They don’t mean anything unless they actually allow you to reason about which code can break if you make a change. Given that, here is how each existing access level is useful: Public means a change could break any code. Internal means only code i

Re: [swift-evolution] classprivate protection level?

Module1 Class A in it's own file extension A in it's own file Class B in it's own file extension B in it's own file Class C in it's own file extension C in it's own file Module 2 obviously i do not want guys from team B and C accessing anything "team A private"

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

> On 29. Oct 2017, at 21:34, Chris Lattner wrote: > > // Magic, allows “overloaded/sugared postfix ()”. > protocol CustomCallable { > func call( …) > } > > The only tricky thing about this is the call part of things. At least in the > case of python, we want something like this: > > foo.ba