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

> On Sep 3, 2016, at 10:15 PM, Jacob Bandes-Storch wrote: > > Perhaps-conversely, what should this code do? > > let nextIndex = foundIndex ?? lastIndex + 1 > > Jacob It's a good counter example. And there's no optional-associative option. -- E > > On Sat, Sep 3,

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> On Sep 4, 2016, at 1:35 AM, Thorsten Seitz wrote: > > > >> Am 03.09.2016 um 18:45 schrieb Justin Jia : >> >> >>> On Sep 4, 2016, at 12:19 AM, Thorsten Seitz wrote: >>> >>> >>> >>> Am 15.08.2016 um 19:05 schrieb

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

> > https://github.com/apple/swift-evolution/blob/master/ > proposals/0140-bridge-optional-to-nsnull.md > > >- What is your evaluation of the proposal? > > I tend to agree with other commenters that NSNull does not seem like an obviously-correct (or -unsurprising) solution to this problem.

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

Perhaps-conversely, what should this code do? let nextIndex = foundIndex ?? lastIndex + 1 Jacob On Sat, Sep 3, 2016 at 9:05 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > Given: `let x = Optional(3)` then > > `let y = 5 + x ?? 2` will not compile > > but > > `let

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

Given: `let x = Optional(3)` then `let y = 5 + x ?? 2` will not compile but `let y = 5 + (x ?? 2)` will. Should NilCoalescingPrecedence be raised? The current operator precedence chain is: BitwiseShiftPrecedence > MultiplicationPrecedence > AdditionPrecedence > RangeFormationPrecedence >

Re: [swift-evolution] SE-0138 UnsafeBytes

> On Sep 3, 2016, at 3:36 PM, Drew Crawford wrote: > > > On September 2, 2016 at 2:36:43 AM, Andrew Trick (atr...@apple.com > ) wrote: > >> After thinking about this for a moment, I like the approach of extending >> UnsafeBytes with

Re: [swift-evolution] SE-0138 UnsafeBytes

On September 2, 2016 at 2:36:43 AM, Andrew Trick (atr...@apple.com) wrote: After thinking about this for a moment, I like the approach of extending UnsafeBytes with release-mode bounds checked versions of subscript, load, and storeBytes. I agree with this, I think it's mostly a question of

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

> On Sep 3, 2016, at 3:01 AM, Pyry Jahkola wrote: > >> On 03 Sep 2016, at 03:17, Charles Srstka via swift-evolution >> > wrote: >> >> With the existing behavior, such mistakes are immediately obvious as >>

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

> On 3 Sep 2016, at 19:13, Brandon Knope wrote: > > Thank you! I was looking for this last night and failed. > > Why do you think {public} isn't included? I don't know, but trying to reimplement __builtin_os_log_format in the overlay seems wrong. It would be better to have a

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

Thank you! I was looking for this last night and failed. Why do you think {public} isn't included? Sent from my iPad > On Sep 3, 2016, at 2:06 PM, Ben Rimmington wrote: > > >> On 3 Sep 2016, at 04:24, Brandon Knope wrote: >> >> I am unsure where to post this…but iOS

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

> On 3 Sep 2016, at 04:24, Brandon Knope wrote: > > I am unsure where to post this…but iOS 10 is introducing a new API for > activity tracing and logging. > > The API has been “Swift-ified” a little, but it still is a little awkward to > use: > > os_log("Sender: %{public}@", log:

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> Am 03.09.2016 um 18:45 schrieb Justin Jia : > > >> On Sep 4, 2016, at 12:19 AM, Thorsten Seitz wrote: >> >> >> >> Am 15.08.2016 um 19:05 schrieb Justin Jia via swift-evolution >> : >> >>> I agree that being

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> On Sep 4, 2016, at 12:19 AM, Thorsten Seitz wrote: > > > > Am 15.08.2016 um 19:05 schrieb Justin Jia via swift-evolution > >: > >> I agree that being explicit is nice and I also like to use `guard`. >> >>

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

I am still not clear how os_log is supposed to be used with Swift if you are not one of the elected ones that can ride his white horse straight into iOS 10+ only land of apps ;). In Objective-C I can use a macro, as wrapper functions are banned, but in Swift? Are availability checks every time

Re: [swift-evolution] The great renaming and the state of new Unified Logging in Swift

> Le 3 sept. 2016 à 06:43, Georgios Moschovitis via swift-evolution > a écrit : > >> Can it be corrected in Swift 4 (breaking changes etc…)? > > Good question. > Maybe the core team should accept additional source-breaking changes in 3.x > releases? I think the

Re: [swift-evolution] [Idea] Use optionals for non-optional parameters

> Am 15.08.2016 um 19:05 schrieb Justin Jia via swift-evolution > : > > I agree that being explicit is nice and I also like to use `guard`. > > But according to my observation, usually it is easier to make mistakes if we > choose to use `guard`. > > Let me give

Re: [swift-evolution] [Pitch]: Require parenthesis for ternary operator '?:' or change its priority

I agree with Thorsten. I would expand on that by arguing that (1) the original motivation identified is inapplicable to Swift; (2) the solution doesn't solve the problem, and creates more problems; (3) the revised solutions are not compatible with the direction of Swift. Argument (1): The only

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

The issue is that when the method doesn't immediately use the values of the array (e.g. stores it for later, or even worse passes them on to another object), the crash appears much later in the program with a message that NSNull doesn't respond to some selector - and that's often hard to debug.

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

+1 as well. I would love to have Data.withUnsafeBytes use this type, and I agree that UnsafeBytes and Data have orthogonal and not overlapping use cases. On Sat, Sep 3, 2016 at 08:59 gs. via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > I think that 'Unsafe' is fine because the

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

+1 I think that 'Unsafe' is fine because the mutable variant is definitely unsafe. I have some audio related code that would benefit greatly from this addition so I am all for it. TJ > On Sep 1, 2016, at 12:10, Dave Abrahams via swift-evolution > wrote: > > >

Re: [swift-evolution] [Pitch]: Require parenthesis for ternary operator '?:' or change its priority

With the replacement, I would prefer just "then-else", which would still clearly carry the meaning of low priority. But yes, this option was explicitly rejected. Unfortunately. I also agree that changing the priority is not a solution. But how about removing priority? The following expression:

Re: [swift-evolution] [Pitch]: Require parenthesis for ternary operator '?:' or change its priority

I don't he's proposing to change the precedence of "?:" per se, just requiring — as part of its syntax — it to be enclosed in parens when it's not by itself: x = condition ? y : z //ok, since it's by itself x = (test || condition) ? y : z //ok, since it's still technically by itself x = test ||

Re: [swift-evolution] [Pitch]: Require parenthesis for ternary operator '?:' or change its priority

The problem you describe is not the priority of the ternary operator but that developers just assume a priority without checking (or learning) whether their assumption is correct. Changing the priority won't solve that problem, it would only shift the problem over to those developers assuming

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

I don't feel confident enough about the Swift–Obj-C interop to cast my own vote but I'd like to question this sentiment: > On 03 Sep 2016, at 03:17, Charles Srstka via swift-evolution > wrote: > > With the existing behavior, such mistakes are immediately obvious as

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

> On 02 Sep 2016, at 22:34, Tony Parker via swift-evolution > wrote: > > > I would instead prefer to look at what we can do with adding API to the > existing types to cover this use case. You point out in the proposal that it > has become customary to use [UInt8]