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

> On Dec 1, 2017, at 11:05 AM, Erica Sadun via swift-evolution > wrote: > > I'd like to put forth that Gameplay Kit offers a perfectly cromulent model of > random number generation and API. Why not take that as a starting point, > Swiftify it so it becomes a cross

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

On Thu, Nov 30, 2017 at 6:55 PM, Nate Cook wrote: > > On Nov 30, 2017, at 6:20 PM, Xiaodi Wu wrote: > > On Thu, Nov 30, 2017 at 5:24 PM, Nate Cook wrote: > >> On Nov 30, 2017, at 4:30 PM, Xiaodi Wu via swift-evolution < >>

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

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

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

> On Nov 30, 2017, at 10:05 PM, Chris Lattner wrote: > > Hi Doug, > > Thank you for the detailed email. I have been traveling today, so I haven’t > had a chance to respond until now. I haven’t read the down-thread emails, so > I apologize if any of this was already

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

> On 1. Dec 2017, at 07:05, Chris Lattner via swift-evolution > wrote: > > Hi Doug, > > Thank you for the detailed email. I have been traveling today, so I haven’t > had a chance to respond until now. I haven’t read the down-thread emails, so > I apologize if

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

On Fri, Dec 1, 2017 at 11:03 AM, Benjamin G via swift-evolution < swift-evolution@swift.org> wrote: > I think the fear most of us , poor developers working with developers of > various skills, is the potential for abuse. I've heard many times that it > isn't a guiding principle for swift, so i'll

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

> On 1 Dec 2017, at 00:54, Xiaodi Wu via swift-evolution > wrote: > >> On Thu, Nov 30, 2017 at 2:24 AM, Douglas Gregor via swift-evolution >> wrote: >> >> >>> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution >>>

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

on Thu, 30 Nov 2017 15:08:55 -0800 Jonathan Hull wrote: > > I think it is important to have Type.random as the base because there are > many types which would conform (not just Int & Double). what would Double.random return though? a "uniformly distributed value" in the range

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

> On Dec 1, 2017, at 12:26 AM, Douglas Gregor wrote: >>> Philosophy >>> Swift is, unabashedly, a strong statically-typed language. >> >> That’s factually incorrect. > > You’re going to have to explain that statement without reference to AnyObject > (we’ll discuss that case

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

I think the fear most of us , poor developers working with developers of various skills, is the potential for abuse. I've heard many times that it isn't a guiding principle for swift, so i'll just reformulate the concern in a more acceptable way : Could your proposal explain how the swift language

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

On Fri, Dec 1, 2017 at 4:17 AM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > > > On 1. Dec 2017, at 07:05, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Hi Doug, > > > > Thank you for the detailed email. I have been traveling today, so

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

> On Nov 30, 2017, at 11:11 PM, Martin Waitz wrote: > > Hello, > >> The collection is a subject which has elements, and we are asking for one of >> them at random. > > it has elements, sure. > And because of its structure, it has a first and a last element and whatever.

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

I’ve been going back and forth on whether I’m for or against the current revision of the proposal and I’d have to say that I am in favor of it as is for the following reasons (many of which have already been stated): It was stated early on in this proposal that Python is not going to be given

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

> On Dec 1, 2017, at 1:30 AM, Chris Lattner wrote: > >> On Dec 1, 2017, at 12:26 AM, Douglas Gregor > > wrote: Philosophy > >>> More problematically for your argument: your preferred approach requires >>> the

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

> On Dec 1, 2017, at 10:07 AM, Greg Titus wrote: > > > >> On Dec 1, 2017, at 9:11 AM, Ben Langmuir via swift-evolution >> > wrote: >> Hey Doug, >> >> I'm very much in favour of reducing the scope of associated

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

On Thu, Nov 30, 2017 at 7:28 PM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > *A Rough Proposal* > I’ve been thinking about this for a bit, and I think there are three ways > in which we should be able to infer an associated type witness: > > >1. Associated type

Re: [swift-evolution] array splatting for variadic parameters

What about calling a framework variadic function that I could not re-declare? like print > 在 2017年12月2日，上午1:26，Tino Heth <2...@gmx.de > 写道： > > There has been a solution to the same problem that’s imho much nicer, because > instead of adding fundamental new syntax, it

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

Hi, > With a protocol defining random() and random(in:), you could write generic > algorithms on things which know how to create themselves from a RNG. With > your approach the RNG has to provide a way to get a random value for each > type you want to support. This is right, if we want a

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

> On Nov 30, 2017, at 4: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

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

On Dec 1, 2017, at 12:26 AM, Douglas Gregor wrote: >> On Nov 30, 2017, at 10:05 PM, Chris Lattner > > wrote: >> Hi Doug, >> >> Thank you for the detailed email. I have been traveling today, so I haven’t >> had a chance to

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

> On Dec 1, 2017, at 9:11 AM, Ben Langmuir wrote: > >> >> On Nov 30, 2017, at 4:28 PM, Douglas Gregor via swift-evolution >> > wrote: >> >> Hello Swift community, >> >> Associated type inference, which is the

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

A somewhat extreme alternative could be the use of IDLs and "libs as services“: A Python lib could aditionally expose its APIs (or a relevant subset of it) via an IDL. Generators would help with the necessary stub and skeleton code on both Python and Swift sides. My impression is that only big

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

Hi Douglas, First of all, thanks very much for looking into this seemingly dark corner of the compiler. This caused us a lot of trouble already. Comments inline. > On 1 Dec 2017, at 12:28 am, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, >

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

+  Dave > On Dec 1, 2017, at 8:35 AM, Jon Gilbert via swift-evolution > wrote: > >> On Nov 30, 2017, at 08:10, Karl Wagner via swift-evolution >> wrote: >> >> Personally, I feel this system is designed to let you write Python, using

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

> On Nov 30, 2017, at 08:10, Karl Wagner via swift-evolution > wrote: > > Personally, I feel this system is designed to let you write Python, using > Swift as a wrapper language - except unlike with Objective-C, Let me paraphrase the proposal—it basically says this

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

On Dec 1, 2017, at 02:44, Xiaodi Wu via swift-evolution wrote: > > So the use case here is, how do we make Swift a viable candidate for doing > those things which today drive users to Python? The answer here is _not_: > build a better Python. Nor does it require,

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

On Fri, Dec 1, 2017 at 4:35 PM, Jon Gilbert via swift-evolution < swift-evolution@swift.org> wrote: > > On Nov 30, 2017, at 08:10, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Personally, I feel this system is designed to let you write Python, > using Swift as a

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

The semantics of the DLR seems fairly similar to Chris’ proposal, does it not? Btw, this makes me think that I would prefer to have one proposal contain both dynamic member lookup and dynamic method calls: it would be kind of silly to have one accepted and not the other. David. > On 1 Dec

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

Responses inline. > On Dec 1, 2017, at 8:35 AM, Jon Gilbert via swift-evolution > wrote: > >> On Nov 30, 2017, at 08:10, Karl Wagner via swift-evolution >> wrote: >> >> Personally, I feel this system is designed to let you write Python,

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

> On Nov 30, 2017, at 5:21 PM, Xiaodi Wu via swift-evolution > wrote: > > On Thu, Nov 30, 2017 at 5:24 PM, Nate Cook > wrote: >> On Nov 30, 2017, at 4:30 PM, Xiaodi Wu via swift-evolution >>

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

> On Dec 1, 2017, at 9:11 AM, Ben Langmuir via swift-evolution > wrote: > Hey Doug, > > I'm very much in favour of reducing the scope of associated type inference. > Can you outline why you believe that (3) is necessary? If I am following > correctly, if we had

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

Should we compare dynamic member lookup to Microsoft's DLR ? https://docs.microsoft.com/en-us/dotnet/framework/reflection-and-codedom/dynamic-language-runtime-overview Quote: The dynamic language runtime (DLR) is a runtime environment that adds a set of services for dynamic languages to the

Re: [swift-evolution] array splatting for variadic parameters

There has been a solution to the same problem that’s imho much nicer, because instead of adding fundamental new syntax, it removes a piece of C-legacy: Basically,instead of func f(args: Int…) you would just declare func f(args: @variadic [Int]) or even func f(args: [Int]) and interpret any

Re: [swift-evolution] array splatting for variadic parameters

> What about calling a framework variadic function that I could not re-declare? > like print That’s a good question — in „regular“ frameworks, variadic functions as we have them now wouldn’t exist anymore, but C is a different story… My expectation (without deep knowledge of the

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

This email reminded me of something… One of the beautiful things about the announcement of Swift in 2014 was that no one saw it coming, even though a whole bunch of signs were in place. One of those signs was Objective-C Modules, which *essentially* describe an API in an abstract syntax, so

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

Paul Cantrell wrote: It seems like this fundamentally alters Swift’s aesthetic of “either an > operation is type-safe, or it’s clear at the point of use that it’s not.” > Should this use an operator other than a period, e.g. `pickle->loads(blob)`? > This is a major concern of mine as well. What

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

> On Dec 1, 2017, at 12:23 AM, Chris Lattner wrote: > >> On Nov 30, 2017, at 6:15 AM, Matthew Johnson wrote: >>> >>> I think better interoperability with Python (and other OO languages in >>> widespread use) is a good goal, and I agree that the