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

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

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

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

> 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 >

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

> 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

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

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:

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

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

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

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

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

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 >

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

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 >

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

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

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 >

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

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

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

> 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 =

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

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

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

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

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

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.

Re: [swift-evolution] Property Getter Return Statement

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