Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

On Thu, Sep 8, 2016 at 12:17 AM, Jacob Bandes-Storch wrote: > On Wed, Sep 7, 2016 at 10:02 PM, Xiaodi Wu wrote: > >> On Wed, Sep 7, 2016 at 11:48 PM, Jacob Bandes-Storch >> wrote: >> >>> On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu wrote: >>> This suggestion has been pitched earlier and I've

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

On Wed, Sep 7, 2016 at 10:02 PM, Xiaodi Wu wrote: > On Wed, Sep 7, 2016 at 11:48 PM, Jacob Bandes-Storch > wrote: > >> On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu wrote: >> >>> This suggestion has been pitched earlier and I've expressed my opinion >>> in those earlier threads, but I'll repeat mys

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

On Wed, Sep 7, 2016 at 11:48 PM, Jacob Bandes-Storch wrote: > On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu wrote: > >> This suggestion has been pitched earlier and I've expressed my opinion in >> those earlier threads, but I'll repeat myself here: >> >> I'm hugely opposed to such changes to the pre

Re: [swift-evolution] [swift-dev] [Swift 4] Organizing source stability

I've filed https://bugs.swift.org/browse/SR-2582 for this. On Tue, Sep 6, 2016 at 10:37 AM, Jordan Rose wrote: > > On Jul 29, 2016, at 21:13, Chris Lattner via swift-dev < > swift-...@swift.org> wrote: > > > On Jul 29, 2016, at 5:55 PM, Jacob Bandes-Storch > wrote: > > Here are a few thoughts:

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

On Mon, Sep 5, 2016 at 1:19 PM, Xiaodi Wu wrote: > This suggestion has been pitched earlier and I've expressed my opinion in > those earlier threads, but I'll repeat myself here: > > I'm hugely opposed to such changes to the precedence table. Those of us > who work with bitwise operators on a reg

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

* What is your evaluation of the proposal? I support this proposal. I work on a framework, and I was actually able to track down a user-reported crash to the lack of this sort of bridging. An engineer overlooked that an `Optional` value passed into an `Any` parameter, would be forwarded to the

Re: [swift-evolution] [Late Pitch] Deprecations, Moves, and Renames

They’re still in Swift 3. Did something go wrong, or will they simply not show up in the final Swift 3.0? > On 10 Aug 2016, at 22:28, Dave Abrahams wrote: > > > on Wed Aug 10 2016, Tim Vermeulen > wrote: > >> Some protocols of SE-0104 seem to be part of the late

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

> On Sep 7, 2016, at 12:52 AM, David Hart via swift-evolution > wrote: > > I’’ve been migrating a project to Swift 3 and a the piece of code below did > not require any modification but had wildly different results: > > let myView = viewController.view > superview.addConstraints([ > NSLay

Re: [swift-evolution] [Review] SE-0138 UnsafeBytes

Yeah it definitely should be it's own proposal. It's just that add we add new Unsafe types, the naming is becoming ridiculous and doesn't clearly express the information developer's need to know when using the types. It's always been a bit iffy, but as I look at the proposal, DaveA's

Re: [swift-evolution] Dot notation as shorthand in subscripts and functions

I certainly agree with this post that extending dot notation shorthand to other parts of swift should be implemented. This would reduce redundancies and make for much cleaner to read code. Surely there must be a solution to any of the potential conflicts like the ones mentioned in the post wit

Re: [swift-evolution] [Review] SE-0138 UnsafeBytes

> On Sep 7, 2016, at 05:48, Karl Wagner via swift-evolution > wrote: > > >> 1. It points into memory that it does not own. The developer must do > >> something to to manage the memory’s lifetime. > > Isn't that just a pointer? Is it really necessary to say "unsafe" and > "pointer"? > > And

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

On Wed, Sep 7, 2016 at 8:11 AM, Vladimir.S wrote: > On 05.09.2016 23:19, Xiaodi Wu via swift-evolution wrote: > >> This suggestion has been pitched earlier and I've expressed my opinion in >> those earlier threads, but I'll repeat myself here: >> >> I'm hugely opposed to such changes to the prece

Re: [swift-evolution] [Review] SE-0138 UnsafeBytes

As much as I would like to get rid of the “Unsafe” prefix, for this change it should imo be considered “out of scope”. Since it is used for the other pointers, it should be used here also. Maybe a separate proposal to get rid of “Unsafe”? Rien > On 07 Sep 2016, at 14:48, Karl Wagner via swift-e

Re: [swift-evolution] [Last second] Precedence of nil-coalescing operator seems too low

On 05.09.2016 23:19, Xiaodi Wu via swift-evolution wrote: This suggestion has been pitched earlier and I've expressed my opinion in those earlier threads, but I'll repeat myself here: I'm hugely opposed to such changes to the precedence table. Those of us who work with bitwise operators on a reg

Re: [swift-evolution] [Review] SE-0138 UnsafeBytes

Isn't every use of "Pointer" in the standard library prefixed by "Unsafe"? If so, we'll want to follow the convention here. On Wed, Sep 7, 2016 at 07:48 Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > >> 1. It points into memory that it does not own. The developer must do > s

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

Hi Igor, Since your proposal would be additive, it probably wouldn't be considered for review until the next phase of Swift evolution. My read of the core team's feedback is that some binary search functionality is welcome, but it's a question of *how* it's designed. When purely additive changes

Re: [swift-evolution] [Review] SE-0138 UnsafeBytes

>> 1. It points into memory that it does not own. The developer must do >> something to to manage the memory’s lifetime. Isn't that just a pointer? Is it really necessary to say "unsafe" and "pointer"? And if we did want to make it explicit, perhaps we say "unowned" instead,

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

do you mean this? public func binarySearch(array: [T], key: T, range: Range, sorted: Bool) -> Int? Best regards, Igor Vasilenko iOS Developer at Yota +7 (999) 527 - 07 - 59 spb.vasile...@gmail.com www.spbvasilenko.github.io >

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

This is mean that my PR/proposal will be as duplicate previous rejected proposal? Or my proposal have a good chance for accept? Best regards, Igor Vasilenko iOS Developer at Yota +7 (999) 527 - 07 - 59 spb.vasile...@gmail.com www.spbvasilenko.github.io

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

Basically for a binary search to work it needs to operate on a sorted array (it is a necessary invariant). It is really interesting when you make a lot of search in the same sorted array, hence I would +1 the sorted array, with initializer from an array. Guillaume DIDIER — ÉCOLE POLYTECHNIQUE

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

> On 7 Sep 2016, at 10:08, Charlie Monroe via swift-evolution > wrote: > > Aside from this being additive (i.e. out of scope for Swift 4), this requires > the array to be sorted in order for the search to work - who will guarantee > this? The caller? What happens when this is called on an arr

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

In my mind, caller should be guarantee that array is sorted. As an example, in Objective-C SDK, NSArray should be is sorted before for using binary search method. But this is a good idea to make a SortedArray. Best regards, Igor Vasilenko iOS Developer at Yota +7 (999) 527 - 07 - 59 spb.vasil

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

Aside from this being additive (i.e. out of scope for Swift 4), this requires the array to be sorted in order for the search to work - who will guarantee this? The caller? What happens when this is called on an array that is not sorted? You likely get nil, while the item is in the array (false n

[swift-evolution] [Proposal] Add Array binary search to the standard library

Introduction Right now, for Array implemented array.contains(element) and array.indexOf(element)for searching in an array. Both of these methods iterate over all elements in the array, starting at index 0, until they find a match. In the worst case (there is no match), they have to iterate over

Re: [swift-evolution] [Review] SE-0140: Bridge Optional As Its Payload Or NSNull

I’’ve been migrating a project to Swift 3 and a the piece of code below did not require any modification but had wildly different results: let myView = viewController.view superview.addConstraints([ NSLayoutConstraint( item: myView, attribute: .left, relatedBy: .equal,