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

> On 3 Dec 2017, at 18:42, Matthew Johnson wrote: > > > > Sent from my iPad > > On Dec 3, 2017, at 10:40 AM, David Hart > wrote: > >> >> >>> On 3 Dec 2017, at 04:11, Matthew Johnson via swift-evolution >>>

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

> On 04 Dec 2017, at 07:47, Joe DeCapo wrote: > > >> On Dec 3, 2017, at 11:35 PM, Letanyan Arumugam via swift-evolution >> > wrote: >> >> I‘m not always the only one writing code (I could inherit a code base).

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

> On Dec 3, 2017, at 11:35 PM, Letanyan Arumugam via swift-evolution > wrote: > > I‘m not always the only one writing code (I could inherit a code base). I’ve > used languages with only dynamic lookup before and knowing about something > doesn’t always help

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

> > 1. a+b is also is a dynamic method call in this example. How would you > explain to a programmer that they have to use single quotes around some > expressions but not others? Operators already have dynamic behaviour with operator overloads. Operators like + fail without warning as well,

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

+1 to Paul's comments Many of the concerns about typos causing runtime bugs scream out to me, "I want to write code that is completely untested and only validated by the compiler". But this is just as bad for a strong, statically typed language as it is for a weak, dynamically typed language

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

> 4 Dec. 2017 11:17 Letanyan Arumugam via swift-evolution > wrote: > > The most minimal way of marking expressions in a way I could think of that > would also remove anyones notion of "this code is fully supported static > Swift code” would be to use the currently

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

Hi I’ve very much been teetering on my preference of having dynamic member lookup sites marked or not and have landed on the side of having it marked. This is for a few reasons: 1. There needs to be some way of conveying that this is not a ‘blessed’ way of writing things. 2. It’s a different

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

> On Dec 3, 2017, at 1:26 PM, Chris Lattner via swift-evolution > wrote: > > On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp wrote: >> >>> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution >>> wrote: >>> >>> That’s a good

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

On Dec 3, 2017, at 3:47 PM, Jonathan Hull wrote: >> That’s a good principle. However, a dynamic member lookup is just a member >> lookup. By that principle, it should look like a member lookup :-) > > The behavior is different though (the invisible guard rails which we

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

On Mon, Nov 27, 2017 at 8:03 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Nov 27, 2017, at 8:57 AM, Mathew Huusko V wrote: > > You're saying that there is universally no inherent difference, and that > all calls "determine if you have called

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

> On Dec 3, 2017, at 5:40 PM, Chris Lattner wrote: > > > >> On Dec 3, 2017, at 3:39 PM, Matthew Johnson > > wrote: >> If that's the concern, then it would be pretty straightforward to restrict dynamic

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

> On Dec 3, 2017, at 9:39 AM, Chris Lattner wrote: > > On Dec 3, 2017, at 5:45 AM, Jonathan Hull > wrote: >> Hi Chris, >> >> I am definitely in favor of providing dynamic features in Swift, and of >> being able to interoperate

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

> On Dec 3, 2017, at 5:38 PM, Chris Lattner wrote: > > > >> On Dec 3, 2017, at 3:34 PM, Matthew Johnson > > wrote: >> >>> >>> On Dec 3, 2017, at 5:14 PM, Chris Lattner >>

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

> On Dec 3, 2017, at 3:39 PM, Matthew Johnson wrote: > >>> If that's the concern, then it would be pretty straightforward to restrict >>> dynamic protocols for stdlib internal use only and expose only PyVal. The >>> trade-off is that all such bridging code would have

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

> On Dec 3, 2017, at 5:14 PM, Chris Lattner wrote: > > >> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu > > wrote: >> >>> >>> and you don’t realize that PyVal’s are involved. However, if you are >>> actively writing the code,

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

> On Dec 3, 2017, at 3:34 PM, Matthew Johnson wrote: > >> >> On Dec 3, 2017, at 5:14 PM, Chris Lattner > > wrote: >> >> >>> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu >>

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

> On Dec 3, 2017, at 5:14 PM, Chris Lattner wrote: > > >> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu > > wrote: >> >>> >>> and you don’t realize that PyVal’s are involved. However, if you are >>> actively writing the code,

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

On Sun, Dec 3, 2017 at 8:26 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp wrote: > > > >> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> That’s a good

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

> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu wrote: > >> >> and you don’t realize that PyVal’s are involved. However, if you are >> actively writing the code, you have access to code completion and other >> things that tell you these types, and if it is important for the

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

On Sun, Dec 3, 2017 at 2:16 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Dec 3, 2017, at 11:36 AM, Chris Lattner wrote: > > On Dec 2, 2017, at 7:11 PM, Matthew Johnson > wrote: > > > This does not improve clarity

Re: [swift-evolution] [RFC] Associated type inference

Would this help sorting out the behavior of typealiases in constrained extensions? If not, please ignore the following and accept my apologies for posting OT. Typealiases in constrained extensions are - and have been, for a long time - very broken. The following program (which is clearly crazy

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

On Sun, Dec 3, 2017 at 2:20 PM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > I believe that adding explicit syntax would be counterproductive to your > goals, and would not make dynamic lookup syntax more clear. I assume that > you would also want the same thing for

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

+1 -Thorsten > Am 03.12.2017 um 21:20 schrieb Karl Wagner via swift-evolution > : > >> >> I believe that adding explicit syntax would be counterproductive to your >> goals, and would not make dynamic lookup syntax more clear. I assume that >> you would also want

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

> Am 03.12.2017 um 20:08 schrieb Magnus Ahltorp : > >> 4 Dec. 2017 03:54 Thorsten Seitz via swift-evolution >> wrote: >> >> The difference is that IUOs are marked by a "!“ whereas dynamic member >> lookups look just like normal member lookups but

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 3, 2017, at 12:44 PM, Jean-Daniel wrote: > > > >> Le 3 déc. 2017 à 09:29, Jose Cheyo Jimenez > > a écrit : >> >> >> >> On Dec 2, 2017, at 11:46 PM, Jean-Daniel >

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> Le 3 déc. 2017 à 09:29, Jose Cheyo Jimenez a écrit : > > > > On Dec 2, 2017, at 11:46 PM, Jean-Daniel > wrote: > >> >> >>> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution >>>

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

> > I believe that adding explicit syntax would be counterproductive to your > goals, and would not make dynamic lookup syntax more clear. I assume that > you would also want the same thing for DynamicCallable too, and operator > overloads, subscripts, and every other operation you perform on

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

> On Dec 3, 2017, at 11:36 AM, Chris Lattner wrote: > > On Dec 2, 2017, at 7:11 PM, Matthew Johnson > wrote: >>> >>> This does not improve clarity of code, it merely serves to obfuscate logic. >>> It is

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

> On Dec 3, 2017, at 12:54 PM, Thorsten Seitz via swift-evolution > wrote: > > The difference is that IUOs are marked by a "!“ whereas dynamic member > lookups look just like normal member lookups but unlike them can fail. We don't even need to bring up IUOs for it

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

On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp wrote: > >> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution >> wrote: >> >> That’s a good principle. However, a dynamic member lookup is just a member >> lookup. By that principle, it should look like a

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

> On Dec 3, 2017, at 10:54 AM, Thorsten Seitz wrote: > >> >> At that point, there would be a general uproar because IUOs have high >> potential for abuse: Swift is “all about” strong types and safety, which >> IUOs undermine. Strong optionals are considered a pain to

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

> 4 Dec. 2017 03:54 Thorsten Seitz via swift-evolution > wrote: > > The difference is that IUOs are marked by a "!“ whereas dynamic member > lookups look just like normal member lookups but unlike them can fail. IUOs are not marked with an "!" by the caller, that's

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

> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution > wrote: > > That’s a good principle. However, a dynamic member lookup is just a member > lookup. By that principle, it should look like a member lookup :-) > > Further, I incorporated some of the conversation

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

> Am 03.12.2017 um 18:36 schrieb Chris Lattner via swift-evolution > : > > On Dec 2, 2017, at 7:11 PM, Matthew Johnson > wrote: >>> >>> This does not improve clarity of code, it merely serves to obfuscate

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

> On Dec 3, 2017, at 11:36 AM, Chris Lattner via swift-evolution > wrote: > > On Dec 2, 2017, at 7:11 PM, Matthew Johnson > wrote: >>> >>> This does not improve clarity of code, it merely serves to obfuscate

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

Sent from my iPad > On Dec 3, 2017, at 10:40 AM, David Hart wrote: > > > >> On 3 Dec 2017, at 04:11, Matthew Johnson via swift-evolution >> wrote: >> >> >> >> Sent from my iPad >> >>> On Dec 2, 2017, at 7:40 PM, Chris Lattner

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

On Dec 3, 2017, at 5:45 AM, Jonathan Hull wrote: > Hi Chris, > > I am definitely in favor of providing dynamic features in Swift, and of being > able to interoperate easily with dynamic languages. I really like the idea > overall. Great! > > I was about to write up a

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

On Dec 2, 2017, at 7:11 PM, Matthew Johnson wrote: >> >> This does not improve clarity of code, it merely serves to obfuscate logic. >> It is immediately apparent from the APIs being used, the API style, and the >> static types (in Xcode or through static declarations)

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

I like Chris's addition to the proposal about only allowing conformance on the original type definition, rather than requiring a class type. https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 > In the discussion

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

> On Dec 3, 2017, at 8:41 AM, David Hart via swift-evolution > wrote: > > > >> On 3 Dec 2017, at 04:11, Matthew Johnson via swift-evolution >> wrote: >> >> >> >> Sent from my iPad >> >>> On Dec 2, 2017, at 7:40 PM, Chris Lattner

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 2, 2017, at 7:58 PM, Jose Cheyo Jimenez wrote: > > Hi Chis, > > Thank you for pushing this forward. > > My only comment is that on the declaration side it would be great to also > have an attribute to communicate that compiler magic is happening. > >

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

One common criticism people keep bringing up is that people will misuse this and end up exposing dynamic api's into general use (and without notation at the call site that draws attention to this, the user may accidentally invoke something dynamic they didn't intend to). I feel like there is

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

> On 3 Dec 2017, at 04:11, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > > On Dec 2, 2017, at 7:40 PM, Chris Lattner > wrote: > >> On Dec 2, 2017, at 2:13 PM, Matthew Johnson

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

> Le 2 déc. 2017 à 12:20, Chris Lattner via swift-evolution > a écrit : > >> *At worst*, you invoke the tool from the command line to build the Swift >> module that corresponds to a given Python module. >> >> py2swift >> >> We could absolutely introduce

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

I *don't* want dynamic calls to stand out. I want seamless interoperability. let arrayOfDogs = [ Python.Module(dog).Dog("Brianna"), Python.Module(dog).Dog("Kevin") ] // Swift array of Python objects let b = arrayOfDogs.sorted() // use Swift 'sort' function on Python objects (invoking Python '<'

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

> What do you think about having a special method ‘dynamic' defined in this > protocol, such that the compiler magic lookup behavior is only available when > chained after that method? I guess „dynamic“ isn’t a common property name, but imho such magic doesn’t feel right, even when there are

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

Hi Chris, I am definitely in favor of providing dynamic features in Swift, and of being able to interoperate easily with dynamic languages. I really like the idea overall. I was about to write up a different idea I had for partially mitigating some of the issues around being able to mistype

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

> … > Beyond that, it is counterproductive to your goals, because it means that > people are far less likely to use to use optional returns. Doing so (which > produces a safer result) would cause a double tax in syntax, and would be a > confusing jumble. I can’t bring myself to do the whole

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 2, 2017, at 11:46 PM, Jean-Daniel wrote: > > > >> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution >> a écrit : >> >> Hi Chris, >> >> Thank you for pushing this forward. >> >> My only comment is that on the