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

> On Dec 10, 2017, at 8:00 AM, Brent Royal-Gordon via swift-evolution > wrote: > > None of which are true of ordinary protocols. Since then, we have added: > > 5. Can only be conformed to in the main declaration. This is the main thing that made me think Letanyan's

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

> On Dec 7, 2017, at 11:29 AM, Letanyan Arumugam wrote: > > I think a better approach would still be to try and get the author of the > type to make the right choice in the first place. After rereading the post you linked to last night

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

> On Dec 7, 2017, at 10:41 AM, Letanyan Arumugam wrote: > > I think warning and error messages would be too much. I’m not concerned about > things being implemented in this way just as long as it’s appropriate. I > would think all language layers like Python should have

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

> On Dec 7, 2017, at 10:12 AM, Letanyan Arumugam via swift-evolution > wrote: > > My original argument about failing for no discernible reason still stands. > precondition is a thought out check for a failing state. member lookup > failures are going to be because

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

> On Dec 7, 2017, at 12:38 AM, Letanyan Arumugam via swift-evolution > wrote: > > My fear is that a design pattern around dynamic members and calls arise that > is used to bypass the perceived initial annoyance of Swifts type system from > new developers that come

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

> On Dec 6, 2017, at 9:45 PM, Paul Cantrell wrote: > > This seems marginally tolerable, but excessive. > > Do we mark every usage of a type that can generate precondition failures or > fatal errors for reasons other than “no such method?” No, we don’t. > > Do we use a

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

> On Dec 6, 2017, at 5:46 PM, Letanyan Arumugam wrote: > > But IUO’s are marked with an “!” to differentiate it from a normal type, > where as DynamicMemberLookup is just a normal protocol conformance. I would > be curious as to what you think of this idea [1]? Would

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

> On Dec 6, 2017, at 12:39 PM, Thorsten Seitz via swift-evolution > wrote: > > IUO is Swift’s equivalent to a null pointer and those are a _hole_ in the > type system (this applies to all type systems having an equivalent to the > null pointer). That is why such

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

> On Dec 6, 2017, at 7:41 AM, Vincent Esche via swift-evolution > wrote: > > If Swift had a rock-solid Generics system at this point and plenty of support > for Meta-Programming via hygienic example-based or procedural macros and/or > compiler plugins, then I'd be

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

> On Dec 5, 2017, at 1:13 PM, Thorsten Seitz via swift-evolution > wrote: > > let result = dynamic x.foo.bar // will crash if foo or bar are not present > > let result = dynamic? x.foo.bar // will return nil if foo or bar are not > present > > // will crash if

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

> On Dec 5, 2017, at 5:47 AM, Benjamin G wrote: > > About C#, in which i did program a few years ago (but before dynamic was in > the language), it already had powerful metaprogramming and introspection > capabilities, as well as very convenient generics and

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

> On Dec 4, 2017, at 11:24 PM, C. Keith Ray wrote: > > 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. > >

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

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

> On Dec 4, 2017, at 7:22 PM, Joe DeCapo via swift-evolution > <swift-evolution@swift.org> 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 >> d

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

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

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

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 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

> 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

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

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