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

> On Dec 20, 2017, at 1:36 PM, Chris Lattner via swift-evolution > wrote: > >> On Dec 19, 2017, at 11:26 PM, Douglas Gregor wrote: >> >>> Beyond that, they are small extensions with low complexity, scale to >>> supporting many different dynamic

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

> On Dec 19, 2017, at 11:26 PM, Douglas Gregor wrote: > >> Beyond that, they are small extensions with low complexity, scale to >> supporting many different dynamic languages over time, require a level of >> engineering effort that is plausible to be built, and do not

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

> On Dec 1, 2017, at 9:37 AM, Chris Lattner wrote: > > On Dec 1, 2017, at 12:26 AM, Douglas Gregor > wrote: >>> On Nov 30, 2017, at 10:05 PM, Chris Lattner >> > wrote: >>> Hi

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

> On Dec 12, 2017, at 9:26 AM, C. Keith Ray wrote: > > in https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 > > > there is this statement: > > "For this reason, the compiler only permits

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

> On 12 Dec 2017, at 19:27, C. Keith Ray via swift-evolution > wrote: > > in https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 > > > there is this statement: > > "For this reason,

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

in https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 there is this statement: "For this reason, the compiler only permits conformance of this protocol on the original type definition, not extensions" and this example: extension JSON : DynamicMemberLookupProtocol {

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

> On Dec 10, 2017, at 13:01, Chris Lattner via swift-evolution > wrote: > >>> On Dec 10, 2017, at 6:00 AM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution >>>

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

On Dec 10, 2017, at 10:04 AM, Paul Cantrell wrote: >> This is looking less like a protocol by the day. The square-peg grooves in >> the round hole are getting deeper and more splintery with every revision. > > The flavor of DynamicMemberLookupProtocol with an explicit member

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

On Dec 10, 2017, at 12:22 PM, Xiaodi Wu via swift-evolution wrote: > The last time I said this, I pointed out that this was a protocol which: > > 1. Has no formal members, > 2. But imposes informal requirements enforced by the compiler, > 3. Permits and uses arbitrary

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

> On Dec 10, 2017, at 6:00 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution >> > wrote: >> >> On Sat, Dec 9, 2017 at 11:20 Steven

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

On Sun, Dec 10, 2017 at 7:59 AM, Brent Royal-Gordon wrote: > On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser > wrote: > >> Just wanted to give my 2¢

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 10, 2017, at 8:00 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution >> > wrote: >> >> On Sat, Dec 9, 2017 at 11:20 Steven

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

> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser > wrote: > Just wanted to give my 2¢ > > ¢ > I don’t like empty protocols—they feel like

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

On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser wrote: > Just wanted to give my 2¢ > > ¢ > I don’t like empty protocols—they feel like an abuse of the feature. > As has been discussed here before, protocols aren’t about bags of syntax but rather about semantics. Empty

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

I’m not at all a fan of _forcing_ IUOs. Depending on the application, return types of Self!, Self?, always-succeeds Self, Self + throws, or Self + fatalError could all be the best approach. In Python and JS, where objects have a dictionary-like shape, IUOs make sense: code can test for member

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

I agree. Instead of a magic protocol, think I'd rather see "@dynamic" used like "@objc" is today. Maybe only applicable to class declarations. Implicitly unwrapped sounds reasonable... need to think on that some more. -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? *

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

Just wanted to give my 2¢ ¢ I don’t like empty protocols—they feel like an abuse of the feature. I think attributes are the right way to go, since this proposal is about enabling syntactic sugar for types which can’t yet be described in the language as-is. This prevents retroactive conformance

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

On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution < swift-evolution@swift.org> wrote: > See below. > > On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution < > swift-evolution@swift.org> wrote: > > Apologies, I may have misunderstood you. What I wanted to say is that I > see no

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

> On 08 Dec 2017, at 18:14, Jean-Daniel wrote: > > > >> Le 8 déc. 2017 à 02:48, Letanyan Arumugam via swift-evolution >> > a écrit : >> >> >> >>> On 07 Dec 2017, at 22:26, Chris Lattner

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

See below. > On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution > wrote: > > Apologies, I may have misunderstood you. What I wanted to say is that I see > no problem allowing "dangerous" stuff that may be abused. You see no problem with danger and abuse? I

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

> Le 8 déc. 2017 à 02:48, Letanyan Arumugam via swift-evolution > a écrit : > > > >> On 07 Dec 2017, at 22:26, Chris Lattner > > wrote: >> >>> >>> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam

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

> On 08 Dec 2017, at 10:04, Nick Keets wrote: > > I think this distills the fears of some of the people that are against this > proposal. To paraphrase, it is the fear that the dynamic type barbarians will > come and pillage our villages. > > I on the other hand would

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

There are fields where there is no swift culture at all, or barely none, for example on the server side. I don’t want to see « swift-django » winning this battle. I like compile-type safety, because i know that in the long term it makes my code more manageable. But in some cases it’s hard to

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

> On 08 Dec 2017, at 00:06, Paul Cantrell wrote: > > >> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam wrote: >> >>> My main objection to the critical responses is that most of the objections >>> are fundamentally cultural, not technical, and are

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

> On 07 Dec 2017, at 22:26, Chris Lattner wrote: > >> >> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam > > wrote: >> > fatalError shouldn’t be used excessively. API surface areas for these > types are going

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

> On Dec 7, 2017, at 2:07 PM, Paul Cantrell via swift-evolution > wrote: > > >> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam wrote: >> >>> My main objection to the critical responses is that most of the objections >>> are fundamentally

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

> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam wrote: > >> My main objection to the critical responses is that most of the objections >> are fundamentally cultural, not technical, and are fear-based, not >> evidence-based. > > The goal of this proposal is to bring

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

> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam wrote: > fatalError shouldn’t be used excessively. API surface areas for these types are going to be massive (infinite technically). I assume many people are going to be writing a lot of code would these

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

Regards Letanyan Arumugam > On 07 Dec 2017, at 21:07, Chris Lattner wrote: > > >> On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution >> > wrote: >> >> >> >>> On 07 Dec 2017, at 17:02,

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

> On Dec 7, 2017, at 9:20 AM, BJ Homer via swift-evolution > wrote: > >> So while it’s theoretically possible to do this, I don’t think it’s a >> concern in practice. The incentives are already in place to encourage doing >> the “right” thing in this case, even

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

> On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution > wrote: > > > >> On 07 Dec 2017, at 17:02, Xiaodi Wu > > wrote: >> >> >> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution >>

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

So the idea is that we shouldn’t allow dynamic lookups and calls to return values without some sort of error handling by default. Avoiding error handling should be an opt in situation. The point of having the default behaviour require error handling is that these protocols will always have at

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

Reading this part of the proposal "Now clients are able to write more natural code like: json[0]?.name?.first?.stringValue which is close to the expressivity of Javascript... while being fully type safe!" gave me the feeling that communication between dynamiclookupable types and static swift

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

> On 07 Dec 2017, at 18:59, Joe DeCapo wrote: > > >> 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

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

> >> The current design says that dynamic and static calls are on equal footing. >> This implies to the programmer that either way of doing things is correct. A >> programmer from a dynamic environment is usually going to choose the dynamic >> way because it’s more powerful and easier to use.

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

> On Dec 7, 2017, at 10:16 AM, Benjamin G wrote: > > > > On Thu, Dec 7, 2017 at 6:01 PM, BJ Homer > wrote: > Benjamin, > > It sounds like your concern is that people might write objects that just > store

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

On Thu, Dec 7, 2017 at 6:01 PM, BJ Homer wrote: > Benjamin, > > It sounds like your concern is that people might write objects that just > store everything in a dictionary, instead of declaring typed properties. > Correct? > > On Dec 7, 2017, at 7:11 AM, Benjamin G via

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

Benjamin, It sounds like your concern is that people might write objects that just store everything in a dictionary, instead of declaring typed properties. Correct? > On Dec 7, 2017, at 7:11 AM, Benjamin G via swift-evolution > wrote: > > I think i answered that

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

>>> I’m talking specifically about fatalError not precondition. fatalError is >>> something that goes out with production code while precondition is used for >>> debugging. I think you would agree a shipped program that has many states >>> of being unrecoverable is not a good design? >> >>

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

RPC predates NSProxy. The "type-safe" version of RPC was CORBA: anybody here use that? Then there was XML-RPC and then SOAP. The most popular version of RPC is HTTP + JSON, because http isn't blocked at network boundaries and because JSON was friendly to JavaScript in the browser. So...

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

> On 07 Dec 2017, at 17:46, Xiaodi Wu wrote: > > On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam > wrote: > > >> On 07 Dec 2017, at 17:02, Xiaodi Wu > > wrote: >> >>

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

Regards Letanyan Arumugam > On 07 Dec 2017, at 17:34, Gwendal Roué wrote: > >> >> Le 7 déc. 2017 à 16:15, Letanyan Arumugam via swift-evolution >> > a écrit : >> >> >> >>> On 07 Dec 2017, at 17:02,

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

Well, mocking was effective and super easy to do proper unit testing with... that must count as a disaster or something ;). Sent from my iPhone > On 7 Dec 2017, at 15:32, C. Keith Ray via swift-evolution > wrote: > > Let's see what disasters were created by people

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

On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam wrote: > > > On 07 Dec 2017, at 17:02, Xiaodi Wu wrote: > > > On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> This seems marginally

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

> Le 7 déc. 2017 à 16:33, C. Keith Ray via swift-evolution > a écrit : > > Let's see what disasters were created by people abusing NSProxy, the ObjC > moral equivalent of a dynamic member lookup type. > > I'm not aware of anything. I'm sure you are ;-) I'm not

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

> Le 7 déc. 2017 à 16:15, Letanyan Arumugam via swift-evolution > a écrit : > > > >> On 07 Dec 2017, at 17:02, Xiaodi Wu > > wrote: >> >> >> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution >>

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

Let's see what disasters were created by people abusing NSProxy, the ObjC moral equivalent of a dynamic member lookup type. I'm not aware of anything. -- C. Keith Ray * https://leanpub.com/wepntk <- buy my book? * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf *

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

> On 07 Dec 2017, at 17:02, Xiaodi Wu wrote: > > > On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution > > wrote: > >> This seems marginally tolerable, but excessive. >> >> Do we mark every

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

On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution < swift-evolution@swift.org> 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

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

On Wed, Dec 6, 2017 at 6:14 PM, Chris Lattner wrote: > On Dec 6, 2017, at 5:41 AM, Vincent Esche via swift-evolution < > swift-evolution@swift.org> wrote: > > Alas while Swift's generics provide a nice basic foundation, they still > have big gaps in what can be expressed

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

> Le 7 déc. 2017 à 13:59, Benjamin G a écrit : > > > > On Thu, Dec 7, 2017 at 1:45 PM, Gwendal Roué > wrote: > >> Le 7 déc. 2017 à 11:00, Benjamin G via swift-evolution >>

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

On Thu, Dec 7, 2017 at 1:45 PM, Gwendal Roué wrote: > > Le 7 déc. 2017 à 11:00, Benjamin G via swift-evolution < > swift-evolution@swift.org> a écrit : > > Until, and if, the “resistance” presents some conceptual explanation of >> how this could cause harm (I’m not asking

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

On Thu, Dec 7, 2017 at 6:41 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > On Dec 6, 2017, at 8:11 PM, Joe DeCapo via swift-evolution < > swift-evolution@swift.org> wrote: > > Has all of this ruined the language thus far? No. Because the Swift core > team doesn’t

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

> Until, and if, the “resistance” presents some conceptual explanation of how > this could cause harm (I’m not asking for anything concrete, just a logical > series of events that causes a plausible problem in practice), my belief is > that the Swift community will see this as unwarranted

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

> 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. > fatalError shouldn’t be used excessively. API surface areas for these types are going to be

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

On Dec 6, 2017, at 8:11 PM, Joe DeCapo via swift-evolution wrote: >> Has all of this ruined the language thus far? No. Because the Swift core >> team doesn’t design, and the Swift community doesn’t adopt, ill-designed >> APIs that turn these facts into problems. > >

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 06 Dec 2017, at 20:54, Joe DeCapo via swift-evolution > wrote: > > >> On Dec 6, 2017, at 12:39 PM, Thorsten Seitz via swift-evolution >> > wrote: >> >> IUO is Swift’s equivalent to a null pointer

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

> Am 06.12.2017 um 02:38 schrieb Chris Lattner : > > On Dec 5, 2017, at 11:13 AM, Thorsten Seitz wrote: >>> This example shows what many on this list don't believe: that any Swift >>> method or member access can fail. If the return value of this "get"

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

On Dec 6, 2017, at 5:41 AM, Vincent Esche via swift-evolution wrote: > Alas while Swift's generics provide a nice basic foundation, they still have > big gaps in what can be expressed through them. > And i'm not talking about HKT or any such more advanced use of

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

On Dec 5, 2017, at 11:51 PM, Jonathan Hull wrote: > Ok, I have changed my mind about the need for a marker, and will accept the > proposal as-is. I realized that these dynamic member lookup types can just > be made inner types, and so I can easily create the .dynamic behavior

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

Apologies, I may have misunderstood you. What I wanted to say is that I see no problem allowing "dangerous" stuff that may be abused. What we shouldn't allow is features that are bug-prone, but this proposal is not that. On Wed, Dec 6, 2017 at 10:48 AM, Tino Heth <2...@gmx.de> wrote: > > During

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

> 6 Dec. 2017 16:51 Jonathan Hull via swift-evolution > wrote: > > Ok, I have changed my mind about the need for a marker, and will accept the > proposal as-is. I realized that these dynamic member lookup types can just > be made inner types, and so I can easily

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

> During the discussion, people emphasized that dynamic features would be > useful for more than Python interop, so if PyVal is the only way to get those > benefits… I have no fear of JS-Bridges utilizing Python, or JSON-libraries > build on top of PyVal — I just said that I don’t think it’s

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

On Tue, Dec 5, 2017 at 6:56 PM, Tino Heth via swift-evolution < swift-evolution@swift.org> wrote: > No specific concerns, but I’m pretty sure developers writing real code > will come up with ideas more bizarre than anything I can think of as an > example. > > During the discussion, people

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

Ok, I have changed my mind about the need for a marker, and will accept the proposal as-is. I realized that these dynamic member lookup types can just be made inner types, and so I can easily create the .dynamic behavior in my own code if I want under the current proposal. I also realized

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

On Dec 5, 2017, at 11:13 AM, Thorsten Seitz wrote: >> This example shows what many on this list don't believe: that any Swift >> method or member access can fail. If the return value of this "get" method >> is an IUO, or not an Optional at all, and doesn't throw, then the

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

> 6 Dec. 2017 04:13 Thorsten Seitz wrote: > > I just wanted to add that the single purpose of a static type system is to > ensure that the methods being called on a receiver are present at runtime and > take arguments of the types known at compile time. Of course the type

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

I see that this feature is fully type safe and has behaviour that is precedent in the language today (It is just sugar after all). I still feel like it is not safe by default and doesn’t discourage the use dynamic programming over static. Obviously for the latter if Swift doesn’t/shouldn’t

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

> I tried to recreate a dynamic BaseDynamicObject based on dictionaries and > your new protocols, but it's pretty hard without the finished implementation > (i will try to recompile swift using your pull request wheneve i got the > time, if i feel people are sincerely interested). Not sure how

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

static type checking is no guarantee of program correctness. you can take a correct, functioning program in Java, for example, strip out all the type declarations and change the syntax to Groovy, and still have a correct, functioning program. (if you avoid methods overloaded on parameter

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

> On Dec 5, 2017, at 12: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 Under the proposal

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

+1 for Thorsten’s `dynamic` and `dynamic?`. -- Howard. > On 6 Dec 2017, at 6:13 am, Thorsten Seitz via swift-evolution > wrote: > > >>> Am 03.12.2017 um 20:04 schrieb Magnus Ahltorp via swift-evolution >>> : >>> >>> 4 Dec. 2017 02:40

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

> Am 03.12.2017 um 20:04 schrieb Magnus Ahltorp via swift-evolution > : > >> 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

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

>> Also, I don’t think anything can prevent all abuses (it’s an subjective >> classification anyways) — people might just use PyVals because dynamic >> behavior, and that would imho be a huge abuse. > > Can you give an example of how someone would use such a PyVal to do something > other than

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

+1 for the proposal Ondrej Barina On Tue, Dec 5, 2017 at 3:16 PM, BJ Homer via swift-evolution < swift-evolution@swift.org> wrote: > > > On Dec 5, 2017, at 7:06 AM, Tino Heth via swift-evolution < > swift-evolution@swift.org> wrote: > > > Also, I don’t think anything can prevent all abuses

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

> On Dec 5, 2017, at 7:06 AM, Tino Heth via swift-evolution > wrote: > > Also, I don’t think anything can prevent all abuses (it’s an subjective > classification anyways) — people might just use PyVals because dynamic > behavior, and that would imho be a huge

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

> "Have the compiler specifically bless individual well-known types, e.g. > Python.PyVal (or whatever it is eventually named) by baking in awareness of > these types into the compiler. Such an approach would require a Swift > evolution proposal to add a new type that conforms to this." > +1 I

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

> Le 5 déc. 2017 à 0:43, C. Keith Ray via swift-evolution > a écrit : > > 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. Most people would expect Java language

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

I use python on a daily basis for scientific computing (PyTorch, Matplotlib, Numpy, Scipy, scikits-learn, etc.). Python is great for doing quick projects, but certain design features of the language make it less ideal for large projects (e.g. whitespace, weak typing, speed, etc.). Swift shares

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

On Tue, Dec 5, 2017 at 12:48 PM, Benjamin G via swift-evolution < swift-evolution@swift.org> wrote: > > > On Tue, Dec 5, 2017 at 4:30 AM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > >> > On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution < >>

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

On Tue, Dec 5, 2017 at 4:30 AM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > On Dec 4, 2017, at 5: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

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

I do not really have a strong opinion on whether this feature should be added to the language, though I will say that if it is, I do not see the need to enforce the visibility of failability on a language level. The feature as proposed is, as has been restated many times, entirely safe. A sane

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

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

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

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

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

  1   2   3   >