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

> Le 3 déc. 2017 à 04:58, Jose Cheyo Jimenez via swift-evolution > a écrit : > > 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. > > Currentl

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

> On Nov 30, 2017, at 2:28 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > Associated type inference, which is the process by which the Swift compiler > attempts to infer typealiases to satisfy associated-type requirements based > on other requirements, has cau

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

I have no input on whether or not this dynamism should be added to Swift. However, *if* we add it, then I strongly prefer that dynamic member lookup should use the exact same syntax as static member lookup, namely a single dot. Member lookup is member lookup, the user-facing behavior is the same i

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

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. Currently it is surprising that a regular looking protocol is providing me so much power. Suggestions: @

Re: [swift-evolution] [Proposal] Random Unification

I don’t have much to say about this other than that I think the discussion seems way too narrow, focusing on spelling rather than on functionality and composability. I consider the “generic random number library” design to be a mostly-solved problem, in the C++ standard library (http://en.cppr

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution > wrote: > > Instead, we ought to make clear to users both the features and the > limitations of this API, to encourage use where suitable and to discourage > use where unsuitable. I like that you're considering the balance here. I'

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

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 wrote: >>> For all those reasons, we really do need something like AnyObject dispatch >>> if we care about working with dynamically typed languages. The design I’m >>> sugge

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

We also know that the current situation isn’t acceptable to a great proposition of the community, that is why we are still discussing the issue! A notable example of reversal of an evolution decision is String’s conformance to Collection. Which I think on the 2nd attempt was a much better decisi

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 2, 2017, at 6:02 PM, Xiaodi Wu via swift-evolution > wrote: > > My point is that our entire design process has been geared towards a > reasonable, best-effort general-use API: It is being designed by community > members who are not specialized in this particular subfield. It is expli

Re: [swift-evolution] [Proposal] Random Unification

On Sat, Dec 2, 2017 at 19:02 Greg Parker wrote: > > On Dec 2, 2017, at 1:09 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon > wrote: > >> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution < >> swift-evolution

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

On Dec 2, 2017, at 2:13 PM, Matthew Johnson wrote: >> For all those reasons, we really do need something like AnyObject dispatch >> if we care about working with dynamically typed languages. The design I’m >> suggesting carefully cordons this off into its own struct type, so it >> doesn’t infe

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 2, 2017, at 1:09 PM, Xiaodi Wu via swift-evolution > wrote: > > On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon > wrote: >> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> That said, I am

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

Sent from my iPad > On Dec 2, 2017, at 4:40 PM, Douglas Gregor wrote: > > > > Sent from my iPhone > >> On Dec 2, 2017, at 1:37 PM, Matthew Johnson wrote: >> >> >>> On Nov 30, 2017, at 6:28 PM, Douglas Gregor via swift-evolution >>> wrote: >>> >>> Hello Swift community, >>> >>> Associ

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

Sent from my iPhone > On Dec 2, 2017, at 1:37 PM, Matthew Johnson wrote: > > >> On Nov 30, 2017, at 6:28 PM, Douglas Gregor via swift-evolution >> wrote: >> >> Hello Swift community, >> >> Associated type inference, which is the process by which the Swift compiler >> attempts to infer ty

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

> On Dec 2, 2017, at 2:44 PM, Chris Lattner wrote: > > On Dec 1, 2017, at 5:50 PM, Matthew Johnson > wrote: This design introduces a significant hole in the type system which is contrary to the spirit of Swift. >>> >>> There is no “hole” in the type sy

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

> On Nov 30, 2017, at 6:28 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > Associated type inference, which is the process by which the Swift compiler > attempts to infer typealiases to satisfy associated-type requirements based > on other requirements, has cau

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

On Sat, Dec 2, 2017 at 2:30 PM, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > Definitely in favour of doing something, I always define the associated > types since I have had so much trouble with the inference. > > Personally I would prefer just 1 and 2 and forget 3. I kn

Re: [swift-evolution] [Proposal] Random Unification

On Sat, Dec 2, 2017 at 6:00 AM, Brent Royal-Gordon wrote: > On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > That said, I am not sure that this proposal should give any pretense of > being suitable for cryptographic use. On implementation, the c

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

On Dec 1, 2017, at 5:50 PM, Matthew Johnson wrote: >>> This design introduces a significant hole in the type system which is >>> contrary to the spirit of Swift. >> >> There is no “hole” in the type system. The proposal is fully type safe. >> >> Further, the addition is absolutely in the spir

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

Definitely in favour of doing something, I always define the associated types since I have had so much trouble with the inference. Personally I would prefer just 1 and 2 and forget 3. I know this would break a lot of code, but I think we should do that because it is the lesser of the evils.

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

Correct me if I’m wrong, but to me it looks like the main objectives to this proposal are cleared once we make it either a DynamicObject (vs a dynamic protocol) or we restrict this protocol adoptions to be only possible from within the main body of types, so in no way it will be possible to ret

Re: [swift-evolution] [Pitch] Generalized supertype constraints

This thread received very light, but positive feedback. I would really like to see this feature added and am willing to draft and official proposal but am not able to implement it. If anyone is interested in collaborating just let me know. > On Nov 24, 2017, at 5:03 PM, Matthew Johnson via s

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

>> I’ve addressed both of these issues above. The approach I am proposing >> requires no language or compiler support, works with existing Swift tooling, >> fits with an existing notion in the language (AnyObject), and can be >> implemented via a Python script. > > I’m very confused, are you s

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

HI Doug, Your approach can definitely work, but before responding with a tradeoff analysis, I’d like to make sure that I understand what you’re suggesting specifically. > On Dec 1, 2017, at 10:39 AM, Douglas Gregor wrote: >> It also doesn’t provide the great tooling experience that you’re see

Re: [swift-evolution] [Proposal] Random Unification

On Dec 1, 2017, at 11:23 PM, David Waite wrote: > > > >> On Dec 1, 2017, at 11:05 AM, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I'd like to put forth that Gameplay Kit offers a perfectly cromulent model >> of random number generation and API. Why not

Re: [swift-evolution] [Proposal] Random Unification

> On Dec 1, 2017, at 10:37 PM, Xiaodi Wu via swift-evolution > wrote: > > That said, I am not sure that this proposal should give any pretense of being > suitable for cryptographic use. On implementation, the code will not have > been audited for that purpose, although the author very rightly