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] [Pitch] Generalized supertype constraints

I see, that makes totally sense. I thought about `inout` only in terms of mutation not reassignment from within the scope itself. Am 10. Dezember 2017 um 17:56:56, Jonathan Keller (jkeller...@icloud.com) schrieb: No, inout should *not* be covariant, since foo can assign any subtype of P to

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] [Pitch] Generalized supertype constraints

No, inout should *not* be covariant, since foo can assign any subtype of P to its parameter, not just F: protocol P {} struct F: P {} struct G: P {} func foo(_ p: inout P) { p = G() } var f = F() foo() // assigns a value of type G to a variable of type F >From Jonathan > On Dec 10, 2017,

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] [Pitch] Generalized supertype constraints

Hello Matthew, I have more more question about the generalized supertype constraints. Does the generalization also covers inout? I found a really annoying case with inout. protocol P {} func foo(_ p: inout P) { print(p) } struct F : P {} var f = F() foo() // won't compile until we