Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> > I think the argument basically is "let's not add another footgun" (because > the design of Swift , for example regarding null handling, is to have less > footguns than other languages). The fact that there are footguns in swift > isn't an argument for adding new ones. Couldn’t have said it be

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On 4 Dec 2017, at 10:42, Vincent Esche via swift-evolution > wrote: > > I think the argument basically is "let's not add another footgun" (because > the design of Swift , for example regarding null handling, is to have less > footguns than other languages). The fact that there are footguns

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

May the question is a little silly. But can this proposal be made on top of property behaviors? ( or the inverse). We already talk about *new kinds* of getters and setters, possibly new sintaxes to call then... I don’t now, maybe I’m overlooking the problem, but feels that , wherever we choose he

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > Some people are big fans of dynamic behavior and this feature will make it > much easier to write code in that style. They will do it without feeling > malicious or considering this to be

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> Chris Lattner wrote: > > let np = Python.import("numpy") > let b = np^.array^([6, 7, 8]) > let y = np^.arange^(24)^.reshape^(2, 3, 4) > > let a = np^.ones^(3, dtype: np^.int32) > let b = np^.linspace^(0, pi, 3) > let c = a+^b > let d = np^.exp^(c

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

> On Nov 29, 2017, at 2:06 PM, Riley Testut wrote: > > >> On Nov 8, 2017, at 11:51 AM, Joe Groff wrote: >> >> In principle it makes sense, but there are implementation challenges we >> didn't have time to consider. It would be nice to make this happen when we >> have the time to make it wo

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

On Mon, Dec 4, 2017 at 1:45 PM, Nick Keets via swift-evolution < swift-evolution@swift.org> wrote: > > > On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> Some people are big fans of dynamic behavior and this feature will make >> it

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 6:45 AM, Nick Keets wrote: > > > > On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > Some people are big fans of dynamic behavior and this feature will make it > much easier to write code in that style.

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution > wrote: > > 1_ From what i understood from this discussion (please correct me if i'm > wrong) python code is already callable from swift right now, without any > modification to the compiler, but then the syntax to *some* very gen

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 1:42 AM, Vincent Esche via swift-evolution > wrote: > > I think the argument basically is "let's not add another footgun" (because > the design of Swift , for example regarding null handling, is to have less > footguns than other languages). The fact that there are footgu

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> This is a bridge to allow easy access to the vast number of libraries that > currently exist in those dynamic language domains, and to ease the transition > of the multitudes of those programmers into Swift. I’ve read several posts that gave me the impression that Python has a huge user base

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 11:15 AM, Tino Heth <2...@gmx.de> wrote: > >> >> This is a bridge to allow easy access to the vast number of libraries that >> currently exist in those dynamic language domains, and to ease the >> transition of the multitudes of those programmers into Swift. > > I’ve read

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

> On Nov 29, 2017, at 9:21 AM, Wallacy via swift-evolution > wrote: > > Distances, yes... Count, not necessarily. It doesn’t really help you to have an extra bit of range for “count" that can’t be expressed in the distance, i.e., where c.count returns a value but c.distance(from: c.startIn

[swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md Hello Swift Community, The review of SE-0191 "Eliminate IndexDistance from Collection” ran from November 27…December 3, 2017. The proposal is accepted. Feedback for this simplification

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> 5 Dec. 2017 02:25 Joe DeCapo via swift-evolution > wrote: > >> On Dec 4, 2017, at 11:15 AM, Tino Heth <2...@gmx.de> wrote: >> >>> >>> This is a bridge to allow easy access to the vast number of libraries that >>> currently exist in those dynamic language domains, and to ease the >>> trans

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Hi Chris, We do the Swift integration with Objective-C via modules. Why wouldn’t that approach work with Python? Or if it would, why would we favor this dynamic member lookup over importing a Python API via a module? Dave > On Nov 26, 2017, at 11:04 PM, Chris Lattner via swift-evolution > wr

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 11:05 AM, Dave DeLong via swift-evolution > wrote: > > Hi Chris, > > We do the Swift integration with Objective-C via modules. Why wouldn’t that > approach work with Python? Or if it would, why would we favor this dynamic > member lookup over importing a Python API via

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> 5 Dec. 2017 01:08 Benjamin G via swift-evolution > wrote: > > Unless DynamicLookup is used to circumvent every compiler warning or errors > thrown at you by the language because your design is unsound. Something like > "ho, yeah swift generics and protocols aren't really working fine togeth

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

It could work, but is a much worse approach IMO. The proposal discusses it here: https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#motivation-and-context https://gist.github.com/lattner/b016

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Awesome. The thread has gotten so long and forked that it’s hard to keep track of what has been asked and answered. I’ll check these out and get back if I have more questions. Thanks! 🙇 Dave > On Dec 4, 2017, at 11:20 AM, Chris Lattner wrote: > > It could work, but is a much worse approach

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> The strongest your argument can be is “someone could use dynamic member > lookup in their API to produce an API with a footgun that hurts their users”. > I submit for your consideration that there are lots and lots of ways that > people can create poor APIs that hurt users. If someone uses

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

What does this mean for ranges of integers, as Xiaodi mentioned in the review thread? Can they still conform to Collection? I think we really need clarification on that aspect. Personally, I would consider it a deal-breaker. - Karl > On 4. Dec 2017, at 18:57, Douglas Gregor via swift-evolutio

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

They will continue to conform to Collection just as they do today. Range.IndexDistance is already an Int. > On Dec 4, 2017, at 10:35, Karl Wagner via swift-evolution > wrote: > > What does this mean for ranges of integers, as Xiaodi mentioned in the review > thread? Can they still conform to

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 10:28 AM, Tino Heth <2...@gmx.de> wrote: > > >> The strongest your argument can be is “someone could use dynamic member >> lookup in their API to produce an API with a footgun that hurts their >> users”. I submit for your consideration that there are lots and lots of >>

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Hi Magnus, You raise an excellent point. The swift journey has been interesting to watch, for sure. I do not believe anyone has ever started with a rigidly typed system and then tried to make it more dynamic (Java JVM dynamicInvocation work by Bracha notwithstanding). There have been several

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

But you noted in that thread that "(Int.min.. On 4. Dec 2017, at 19:39, Ben Cohen via swift-evolution > wrote: > > They will continue to conform to Collection just as they do today. > Range.IndexDistance is already an Int. > >> On Dec 4, 2017, at 10:35, Karl Wagner via swift-evolution >> mail

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

On Dec 4, 2017, at 10:47 AM, Eagle Offshore via swift-evolution wrote: > Hi Magnus, > > You raise an excellent point. > > The swift journey has been interesting to watch, for sure. I do not believe > anyone has ever started with a rigidly typed system and then tried to make it > more dynamic

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> It is easy to forsee the impact. Simply look to other language communities > that have done similar things. C# added “dynamic” late in its evolution, > which has even more power than what is being proposed here. What evidence of > abuse have you seen? None, and I have little fear of abuse

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

On 04.12.2017 19:27, Joe DeCapo via swift-evolution wrote: On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution > wrote: 1_ From what i understood from this discussion (please correct me if i'm wrong) python code is already callable from swift right no

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

> On Dec 4, 2017, at 10:53, Karl Wagner wrote: > > But you noted in that thread that "(Int.min.. you can fit in an Int, and causes a crash today. If we remove IndexDistance, > that behaviour is locked-in, is it not? > That behavior is going to be locked in whether we like it or not when we d

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 12:12 PM, Vladimir.S via swift-evolution > wrote: > > Probably the correct way to have dynamic calls in Swift is to 'mark' such > code with special flag and we need to find it. For example: > > > // Python:d = np.array([1, 2, 3], dtype="i2") > > // Future Swift: l

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 3, 2017, at 08:33 , Michel Fortin via swift-evolution > wrote: > > Instead of looking for a module in the _module search path_, the compiler > would run a command-line tool called `py2swift` found in an _import tool > search path_. The tool generates the module on the fly before ret

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> Yes, IMO such code should be second class citizen in Swift. Just have the compiler emit "your code is bad and you should be ashamed of it." -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf * http://agilesolutionspace

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

I'm curious to get some feedback on this from people who would prefer a marker at every call site where a `DynamicMemberLookup` or `DynamicCallable` type is used. I haven't done any C# development before, but I read a few articles on the usage of `dynamic` and `var` in the language. I found it i

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 7:22 PM, Joe DeCapo via swift-evolution > wrote: > >> The first one, has no static type info, no compile time checking, it's not >> self documenting, no type inference so people will be forced to use a >> dynamic reference at the call site to store the result, leading to

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution > wrote: >> The first one, has no static type info, no compile time checking, it's not >> self documenting, no type inference so people will be forced to use a >> dynamic reference at the call site to store the result, leading to more

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 1:12 PM, Vladimir.S via swift-evolution > wrote: > > On 04.12.2017 19:27, Joe DeCapo via swift-evolution wrote: >>> On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> 1_ From what i understood from this discu

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 4, 2017, at 9:30 PM, Chris Lattner > wrote: > > I personally am far more interested in getting to the bottom of Doug’s > concerns - it isn’t clear to me what exactly his preferred direction actually > is, but that discussion is based on engineering tradeoffs

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Not everyone uses the IDE as a crutch for writing code. As someone who has used many languages, editors, and operating systems, I don't rely on autocomplete and sometimes turn it off because it gets in my way. my experience with C# was sometimes frustrating because it could be hard to find the

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

BTW, Java via JNI would be another good application of this proposal. I once used a JNI wrapper library in C++ and it was pretty hairy and tedious. I think we might want to declare a "Python object" as implementing swift protocols. If the methods that implement a protocol are NOT implemented in