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

Right—again, this is yet another difference between two things both named “random” in this proposal. Almost always, when we say “give me two random integers,” we want independent random samples from the set of all integers. But for collections, a very common (and probably more common operation) is

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

Hi Erica, > Doesn't `choose` usually take two arguments, the `count` to choose > (presumably defaulting to 1) and the collection to choose `from`? This might be useful for collections, when you want to draw several elements without drawing the same element twice. For ranges of random numbers

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

> On 30. Nov 2017, at 09:24, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution >> > wrote: >> >> I’d like to formally propose the

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

+1 to the concerns voiced by Doug, Matthew and others. I , too, would prefer a generator which generates a statically typed bridge instead of the dynamic lookup ature proposed which effectively undermines Swift's static type system. -Thorsten > Am 30.11.2017 um 15:15 schrieb Matthew Johnson

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

Sent from my iPhone > On Nov 30, 2017, at 00:24, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution >> wrote: >> >> I’d like to formally propose the inclusion of

[swift-evolution] [Accepted] SE-0189 - Restrict Cross-module Struct Initializers

Hello Swift Community, The review of of “SE-189: Restrict Cross-module Struct Initializers” ran from November 14 to 21, 2017. This proposal has been accepted. During the review, most of the feedback voiced support that this was a necessary change for the library evolution (API resilience)

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

> On Nov 29, 2017, at 2:07 PM, Riley Testut wrote: > > >> On Nov 9, 2017, at 9:01 AM, Philippe Hausler > > wrote: >> >> I have personally filed a few bugs on this; and I definitely consider it a >> bug that we cannot

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

On 30.11.2017 17:15, Matthew Johnson via swift-evolution wrote: Sent from my iPad On 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] array splatting for variadic parameters

What happened with this proposal? This looks easy to implement. func sumOf(numbers: Int...) -> Int { ... } typealias Function = [Int] -> Int let sumOfArray = unsafeBitCast(sumOf, Function.self) sumOfArray([1, 2, 3]) > Hello everyone. > > I understand that topic has already been

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

Doug and others have brought up some great points, and I think Doug’s idea of a common infrastructure for importing declarations from other languages is _extremely_ attractive for the long-term future of Swift. However, unlike this proposal, that will (I imagine as a non-compiler engineer) be

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

> On Nov 30, 2017, at 1:01 PM, Zach Wolfe wrote: > > Doug and others have brought up some great points, and I think Doug’s idea of > a common infrastructure for importing declarations from other languages is > _extremely_ attractive for the long-term future of

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

> On Nov 30, 2017, at 3:40 PM, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 30, 2017, at 1:01 PM, Zach Wolfe > > wrote: >> >> Doug and others have brought up some great points, and I

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

I would personally go with: Int.random //Returns a random Int Int.random(in: ClosedRange) //Works for Comparable types. Gives a result from the closed range. Closed Range is never empty. [0,2,3].randomElement //Returns a random element from the collection Then a version

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

For collections, I think we should call returning a random element -randomElement, and choosing a random element without replacement -popRandomElement var list = [1,2,3,4] let a:Int? = list.randomElement //List is still [1,2,3,4] and ‘a’ contains one of the elements let b:Int? =

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

On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution wrote:I would personally go with: Int.random //Returns a random Int“Type.random” is so rarely used as to not be worth the addition, IMO. If you really need a random element from the *entire* domain, then I

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

> On Nov 30, 2017, at 5:02 PM, Jonathan Hull wrote: > > >> On Nov 30, 2017, at 3:52 PM, Dave DeLong > > wrote: >> >> What is the useful distinction between generating a random value, and >> choosing a random element from a

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

Another common reason to use a custom RNG is to be able to use a seed for repeatability, which would (I think) work properly here. > 2017/11/30 18:11、Xiaodi Wu のメール: > > On Thu, Nov 30, 2017 at 5:29 PM, Jonathan Hull > wrote: > >>

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

> On Nov 30, 2017, at 3:46 PM, Martin Waitz wrote: > > Hello Jonathan, > >> For collections, I think we should call returning a random element >> -randomElement, and choosing a random element without replacement >> -popRandomElement > > I disagree because I don’t think

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

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 < > swift-evolution@swift.org> wrote: > > On Thu, Nov 30, 2017 at 3:58 PM, Dave DeLong via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> On Nov

[swift-evolution] [RFC] Associated type inference

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 caused both implementation problems and user confusion for a long time. Some of you might

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

On Wed, Nov 29, 2017 at 10:46 AM, Ben Cohen wrote: > You can argue the current status is a bug, but… > > Welcome to Apple Swift version 4.0.1 (swiftlang-900.0.67 clang-900.0.38). > Type :help for assistance. > 1> CountableRange.IndexDistance.self > $R0: Int.Type = Int >

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

> On Nov 30, 2017, at 4:11 PM, Xiaodi Wu wrote: > > On Thu, Nov 30, 2017 at 5:29 PM, Jonathan Hull > wrote: > >> On Nov 30, 2017, at 2:30 PM, Xiaodi Wu > > wrote: >> >> On Thu,

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

> 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 >>> wrote: >>> On Thu, Nov 30, 2017 at 3:58 PM, Dave

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

On Thu, Nov 30, 2017 at 3:58 PM, Dave DeLong via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > > I would personally go with: > > Int.random //Returns a random Int > > > “Type.random”

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

> On Nov 30, 2017, at 3:48 PM, Paul Cantrell via swift-evolution > wrote: > > > >> On Nov 30, 2017, at 3:40 PM, Douglas Gregor via swift-evolution >> > wrote: >> >> >> >>> On Nov 30, 2017, at 1:01 PM,

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

> On Nov 30, 2017, at 4:08 PM, Jonathan Hull wrote: > > >> On Nov 30, 2017, at 1:58 PM, Dave DeLong > > wrote: >> >> >> >>> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution >>>

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

> On Nov 30, 2017, at 4:30 PM, Xiaodi Wu via swift-evolution > wrote: > > On Thu, Nov 30, 2017 at 3:58 PM, Dave DeLong via swift-evolution > > wrote: > > >> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via

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

> On Nov 30, 2017, at 3:19 PM, Dave DeLong wrote: > > > >> On Nov 30, 2017, at 4:08 PM, Jonathan Hull > > wrote: >> >> >>> On Nov 30, 2017, at 1:58 PM, Dave DeLong >> > wrote:

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

Hello Jonathan, > For collections, I think we should call returning a random element > -randomElement, and choosing a random element without replacement > -popRandomElement I disagree because I don’t think that the random data is a property of the collection. The collection is not the subject

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

On Thu, Nov 30, 2017 at 2:24 AM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > I’d like to formally propose the inclusion of user-defined dynamic member >

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

Hi, >>> This is redundant. In order to pick a random element, you’re saying I >>> should have to do “Int.random(0 ..< 10)”? The redundancy here is that I >>> have to specify Int twice: once for the “.random” call, and again for the >>> type of the range. We can do better than that. > > I

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

Agreed. Type.random should call Type.random(using:) with the (publicly available) default. In fact, if we wanted to make it Type.random() it should basically be the default value of ‘using:’ Thanks, Jon > On Nov 30, 2017, at 3:03 PM, TellowKrinkle wrote: > >

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

I agree that the RNG should be public. GameplayKit uses customizable distributions including normal and uniform. https://developer.apple.com/library/content/documentation/General/Conceptual/GameplayKit_Guide/RandomSources.html -- E > On Nov 30, 2017, at 4:03 PM, TellowKrinkle via

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

Don’t forget that if you already know the type, you can leave out the type name, so for example, to supply a random bool a function, you could just use `.random()` instead of `Bool.random()`, which removes a lot of the extra redundant type names. > 2017/11/30 17:19、Dave DeLong

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

> On Nov 30, 2017, at 4:46 PM, Jonathan Hull wrote: > >> >> On Nov 30, 2017, at 3:19 PM, Dave DeLong > > wrote: >> >> >> >>> On Nov 30, 2017, at 4:08 PM, Jonathan Hull >> > wrote:

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

> On Nov 30, 2017, at 3:52 PM, Dave DeLong wrote: > > What is the useful distinction between generating a random value, and > choosing a random element from a collection of all possible values? I don’t have to generate (or keep in memory) that collection. I gave an

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

Whether or not it’s possible to hide, I think that the default RNG should be exposed publicly, so that functions like `CustomType.random(using:)` will take a RandomSource property instead of just using the system RNG, allowing someone to specify a different RNG (maybe a seedable PRNG for

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

> On Nov 30, 2017, at 1:58 PM, Dave DeLong wrote: > > > >> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution >> > wrote: >> >> I would personally go with: >> >> Int.random //Returns a

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

On Thu, Nov 30, 2017 at 10:48 PM, Paul Cantrell via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 30, 2017, at 3:40 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Nov 30, 2017, at 1:01 PM, Zach Wolfe > wrote:

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

> On Nov 30, 2017, at 2:30 PM, Xiaodi Wu wrote: > > On Thu, Nov 30, 2017 at 3:58 PM, Dave DeLong via swift-evolution > > wrote: > > >> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution >>

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

Hi Doug, > On Nov 30, 2017, at 4:28 PM, Douglas Gregor via swift-evolution > wrote: > > I think this approach is more predictable and more implementable than the > current model. I’m curious whether the above makes sense to someone other > than me, and whether it

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

> On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution > wrote: > > I’d like to formally propose the inclusion of user-defined dynamic member > lookup types. > > Here is my latest draft of the proposal: >

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

On Thu, Nov 30, 2017 at 9:24 AM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 26, 2017, at 10:04 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > > I’d like to formally propose the inclusion of user-defined dynamic member >

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

Sent from my iPad > On 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 >> wrote: >> >> I’d like to formally propose the inclusion of

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

> On 28. Nov 2017, at 00:20, Martin Waitz via swift-evolution > wrote: > > Hello, > >> Maybe we call the default RNG instance `random`, and then give the >> `random(in:)` methods another name, like `choose(in:)`? >> >> let diceRoll = random.choose(in: 1...6)

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

> 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 implementation of the >> feature described is straight-forward and not terribly

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

> On Nov 30, 2017, at 10:26 PM, Slava Pestov wrote: > > > >> On Nov 30, 2017, at 10:23 PM, Chris Lattner via swift-evolution >> > wrote: >> >> The difference between it and AnyObject lookup is that AnyObject

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

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 discussed: > I think better interoperability with Python (and other OO languages in >

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

On Nov 30, 2017, at 3:46 AM, Matt Diephouse wrote: > The examples in the proposal are very shallow, highlighting single lookups. > But what are the types of the returned values? The Python example is recursive: PyVal is returned and is the source of

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

> On Nov 30, 2017, at 3:54 PM, Xiaodi Wu wrote: > While we shouldn’t necessarily avoid a feature simply because it can be used > distastefully, consider something like this: > > public extension NSObject : DynamicMemberLookupProtocol, > DynamicCallableProtocol { … }

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

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. But that random element is not an inherent property of the collection. I find it much

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

> Le 1 déc. 2017 à 00:54, Xiaodi Wu via swift-evolution > a écrit : > > As I wrote in the earlier thread, I think this is the wrong way to reason > about the use case--and a counterproductive one that effectively rejects the > legitimacy of dynamic language interop

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

> On Nov 30, 2017, at 10:23 PM, Chris Lattner via swift-evolution > wrote: > > The difference between it and AnyObject lookup is that AnyObject lookup is: > > b) type unsafe Can you explain in what sense AnyObject lookup is type unsafe where your proposal is type

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

> On Nov 30, 2017, at 10:31 PM, Chris Lattner wrote: > > The Objective-C runtime does not track the type of members or methods. Ok, this statement isn’t factually true: I’ll admit that there are two related things to this: the GNU ObjC runtime does track some method types,

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

> Le 1 déc. 2017 à 08:38, Gwendal Roué a écrit : > > In this context, I too am concerned with retroactive conformance. If it were > forbidden, it would make it very clear where the dynamic scope starts and > ends: In Chris's playground, it is very clear that you have