Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

2017-10-11 Thread Kelvin Ma via swift-evolution
On Wed, Oct 11, 2017 at 6:06 PM, Nevin Brackett-Rozinsky < nevin.brackettrozin...@gmail.com> wrote: > On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution < > swift-evolution@swift.org> wrote: > >> Yes, a 0-ary operator like that would have to be hard baked into the >> language itself. >>

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

2017-10-11 Thread Nevin Brackett-Rozinsky via swift-evolution
On Wednesday, October 11, 2017, Kelvin Ma via swift-evolution < swift-evolution@swift.org> wrote: > Yes, a 0-ary operator like that would have to be hard baked into the > language itself. > Actually, you can just make a subscript which takes a function as an argument, and call it by passing in th

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

2017-10-11 Thread Taylor Swift via swift-evolution
> On Oct 11, 2017, at 3:42 PM, Ben Cohen wrote: > > > >> On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution >> wrote: >> >> there is no way to allow one-sided subscripting, but disallow two-sided >> subscripting for the memory API > > One-sided subscripting is just shorthand for

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

2017-10-11 Thread Ben Cohen via swift-evolution
> On Oct 11, 2017, at 1:15 PM, Kelvin Ma via swift-evolution > wrote: > > there is no way to allow one-sided subscripting, but disallow two-sided > subscripting for the memory API One-sided subscripting is just shorthand for “from here to the end” (or from the start to/through here). If a o

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

2017-10-11 Thread Mike Kluev via swift-evolution
On 11 October 2017 at 18:30, Mike Kluev wrote: > > On 7 Oct 2017, at 04:24, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> >> These aren’t the forms I was suggesting, what I meant was: >> > >> > extension Int { >> > init(randomInRange: Countable{Closed}Range)

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

2017-10-11 Thread Kelvin Ma via swift-evolution
I should also add I think I remember the String people trying to add collection[] empty subscripts to the language but I don’t remember that ever going through. On Wed, Oct 11, 2017 at 3:15 PM, Kelvin Ma wrote: > Yes, a 0-ary operator like that would have to be hard baked into the > language its

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

2017-10-11 Thread Kelvin Ma via swift-evolution
Yes, a 0-ary operator like that would have to be hard baked into the language itself. Of course, the subscript notation has much more serious problems, there is no way to allow one-sided subscripting, but disallow two-sided subscripting for the memory API, while still allowing two-sided subscriptin

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

2017-10-11 Thread Nevin Brackett-Rozinsky via swift-evolution
I believe Kelvin was asking about the usage of ellipsis *by itself*, as in Xiaodi’s example, “newBuffer[...]”. Nevin On Wed, Oct 11, 2017 at 2:42 PM, Anders Ha via swift-evolution < swift-evolution@swift.org> wrote: > ICYMI, SE-0172 was the proposal of one sided range and it has been > implemen

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

2017-10-11 Thread Dave DeLong via swift-evolution
A massive +1 for this approach too. As a “least competent engineer” when it comes to random numbers, I’d really appreciate having safeguards in place to keep me from inadvertently shooting myself in the foot. Dave > On Oct 11, 2017, at 11:21 AM, Cory Benfield via swift-evolution > wrote: >

Re: [swift-evolution] [Proposal] implicit `if let`

2017-10-11 Thread BJ Homer via swift-evolution
This has been proposed and rejected a few times, actually. You can see it in the Swift-Evolution “Commonly Rejected Changes” document here: https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md -BJ

Re: [swift-evolution] SE-1084 (B): buffer pointer partial initialization API

2017-10-11 Thread Anders Ha via swift-evolution
ICYMI, SE-0172 was the proposal of one sided range and it has been implemented as part of 4.0. https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md Regards Anders > On 11 Oct 2017, at 4:43 AM, Kelvin Ma via swift-evolution > wrote: > > > > On Tue, Oct 10

[swift-evolution] [Proposal] implicit `if let`

2017-10-11 Thread Manuel Carrasco Molina via swift-evolution
Hi, We usually do this If let foo = foo { // bar } What if the compiler would understand If let foo { // bar } As if the `= foo` would be there? I’d find it great syntactic sugar. ___ swift-evolution mailing list swift-evolution@swift.org https://li

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

2017-10-11 Thread Mike Kluev via swift-evolution
> On 7 Oct 2017, at 04:24, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > >> These aren’t the forms I was suggesting, what I meant was: > > > > extension Int { > > init(randomInRange: Countable{Closed}Range) > > } > > > > which gives: > > let x = Int(randomInRa

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

2017-10-11 Thread Cory Benfield via swift-evolution
I strongly recommend building the padded room. Average to good engineers (which I assume is intended to be a proxy for “engineers who know about CSPRNGs and have considered their personal threat model”) know enough to work out what kind of RNG they have available and to use the one most appropr

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

2017-10-11 Thread Kevin Nattinger via swift-evolution
IMO, if we have the extensions on Int(eger)/Float(ingPoint)/Array (RandomAccessSequence?), they should just be for convenience and with a sane default RNG*, and users that need more should just use methods on the RNGs directly. *: I don't think the default necessarily needs to be a CSRNG; if th

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

2017-10-11 Thread Jeremy Pereira via swift-evolution
I’m a bit late to the party on this one, but has anybody considered the fact that you need a way for the user of the interface to override the default random number source? For example, some applications require a cryptographically secure source, others might eschew perfect entropy for speed. S

Re: [swift-evolution] Property Getter Return Statement

2017-10-11 Thread Mike Kluev via swift-evolution
On Tue Oct 10 15:02:37 CDT 2017 Slava Pestov spestov at apple.com wrote: >> I’m minorly opposed, because it feels like a slippery slope. What about function bodies? etc >> >> func foo() -> Int { 3 } // should this be allowed? a small -1 or even: func foo() { 3 } // Int return type inferred as w