Re: [swift-evolution] [Late Pitch] open/public protocols

On 8/22/2016 2:40 PM, Adrian Zubarev via swift-evolution wrote: > > Hello dear Swift community, > > I was updating some of my libraries where I noticed that the new > |open| access modifier made the |public| modifier inconsistent in one way. > > Conformances to protocols is logically the same as

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

> On Aug 24, 2016, at 10:40 PM, jaden.gel...@gmail.com wrote: > > Why is exposing an Optional as an opaque box less error prone than an NSNull? > That doesn't seem obviously true to me. Firstly, to answer your question: It is less error-prone because the error is more obvious. If an

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

> The problem is that NSNull is in fact rare in Cocoa. I couldn't agree more. I think this proposal is quite dangerous for (often legacy) Objective C codebases where checking for NSNull is not common practice. Since Optionals are not a construct in Objective C, I don't see any reason for why

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

> On Aug 25, 2016, at 5:00 AM, Charles Srstka via swift-evolution > wrote: > >> On Aug 24, 2016, at 8:27 PM, Greg Parker via swift-evolution >> > wrote: >> >>> On Aug 23, 2016, at 3:36 PM, Douglas Gregor

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

Why is exposing an Optional as an opaque box less error prone than an NSNull? That doesn't seem obviously true to me. > On Aug 24, 2016, at 8:00 PM, Charles Srstka via swift-evolution > wrote: > >>> On Aug 24, 2016, at 8:27 PM, Greg Parker via swift-evolution >>>

Re: [swift-evolution] Pitch: really_is and really_as operators

On Wed, Aug 24, 2016 at 10:07 PM, Charles Srstka wrote: > On Aug 24, 2016, at 10:00 PM, Xiaodi Wu wrote: > > > On Wed, Aug 24, 2016 at 9:58 PM, Charles Srstka > wrote: > >> On Aug 24, 2016, at 9:51 PM, Xiaodi Wu

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 24, 2016, at 10:00 PM, Xiaodi Wu wrote: > > On Wed, Aug 24, 2016 at 9:58 PM, Charles Srstka > wrote: >> On Aug 24, 2016, at 9:51 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

> On Aug 24, 2016, at 8:27 PM, Greg Parker via swift-evolution > wrote: > >> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution >> > wrote: >> >> Proposed solution >> >> When an Optional

Re: [swift-evolution] Pitch: really_is and really_as operators

On Wed, Aug 24, 2016 at 9:58 PM, Charles Srstka wrote: > On Aug 24, 2016, at 9:51 PM, Xiaodi Wu wrote: > > On Wed, Aug 24, 2016 at 9:47 PM, Xiaodi Wu wrote: > >> Works on Linux :) >> > > And besides, on any platform where

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 24, 2016, at 9:51 PM, Xiaodi Wu wrote: > > On Wed, Aug 24, 2016 at 9:47 PM, Xiaodi Wu > wrote: > Works on Linux :) > > And besides, on any platform where `type(of: bar) != NSString`, why should > you expect `bar

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 24, 2016, at 8:09 PM, Jaden Geller wrote: > > Scratch that last message. Determining what's stored in `Any` was Charles's > original goal, and what I said made no sense. This should work: > > func unbridgedCast(_ x: T, to: U.Type) -> U? { > guard

Re: [swift-evolution] Pitch: really_is and really_as operators

On Wed, Aug 24, 2016 at 9:51 PM, Xiaodi Wu wrote: > On Wed, Aug 24, 2016 at 9:47 PM, Xiaodi Wu wrote: > >> Works on Linux :) >> > > And besides, on any platform where `type(of: bar) != NSString`, why should > you expect `bar really_is NSString == true`?

Re: [swift-evolution] Pitch: really_is and really_as operators

On Wed, Aug 24, 2016 at 9:47 PM, Xiaodi Wu wrote: > Works on Linux :) > And besides, on any platform where `type(of: bar) != NSString`, why should you expect `bar really_is NSString == true`? Isn't bar *not really* NSString? On Wed, Aug 24, 2016 at 9:44 PM, Charles Srstka

Re: [swift-evolution] Pitch: really_is and really_as operators

Works on Linux :) On Wed, Aug 24, 2016 at 9:44 PM, Charles Srstka wrote: > On Aug 24, 2016, at 7:42 PM, Xiaodi Wu wrote: > > > import Foundation > > let foo: Any = "Hello" > type(of: foo) == String.self // true > type(of: foo) == NSString.self //

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 24, 2016, at 7:42 PM, Xiaodi Wu wrote: > > import Foundation > > let foo: Any = "Hello" > type(of: foo) == String.self // true > type(of: foo) == NSString.self // false > > let bar: Any = "Hello" as NSString > type(of: bar) == String.self // false > type(of: bar)

Re: [swift-evolution] Pitch: really_is and really_as operators

On Wed, Aug 24, 2016 at 9:25 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 24, 2016, at 9:09 PM, Robert Widmann via swift-evolution < > swift-evolution@swift.org> wrote: > > I have 3 qualms with this proposal as it stands: > > - type(of:) will never lie to

Re: [swift-evolution] Pitch: really_is and really_as operators

> On Aug 24, 2016, at 9:09 PM, Robert Widmann via swift-evolution > wrote: > > I have 3 qualms with this proposal as it stands: > > - type(of:) will never lie to you. > > The only question it won’t answer to your satisfaction is the dynamic type of > the NSString

Re: [swift-evolution] Pitch: really_is and really_as operators

I have 3 qualms with this proposal as it stands: - type(of:) will never lie to you. The only question it won’t answer to your satisfaction is the dynamic type of the NSString you boxed up as an Any. - No more keywords without significant justification. I don’t buy the performance use case

Re: [swift-evolution] Pitch: really_is and really_as operators

I used this several months ago for extracting data from Any: // Dynamic cast without bridging func dynamicCast(_ type: T.Type, _ v: Any)->T? { guard let result = v as? T where v.dynamicType is T.Type else { return nil; } return result } from

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution > wrote: > > Proposed solution > > When an Optional value is bridged to an Objective-C object, if it contains > some value, that value should be bridged; otherwise, NSNull or another > sentinel

Re: [swift-evolution] Pitch: really_is and really_as operators

Though this performs an *extra* check over just `x as! U`, it avoids bridging conversions. I don't think this extra check matters though because you wouldn't be using `Any` in code that's performance critical enough for this to matter, so I'm currently -1 on this proposal. > On Aug 24, 2016,

Re: [swift-evolution] Pitch: really_is and really_as operators

Scratch that last message. Determining what's stored in `Any` was Charles's original goal, and what I said made no sense. This should work: func unbridgedCast(_ x: T, to: U.Type) -> U? { guard type(of: x) is U.Type else { return nil } return x as! U } if let x = unbridgedCast(x,

Re: [swift-evolution] Pitch: really_is and really_as operators

Actually, the code I proposed does not work. First of all, it doesn't work for subtype relations. This can easily be fixed though by changing `== U.self` to `is U`. More importantly though, it fails when `T` is an existential since `type(of:)` looks within the existential to determine the type.

Re: [swift-evolution] Pitch: really_is and really_as operators

Taking that suggestion a step further, it's pretty easy to define a function that performs this sort of casting without bridging. func unbridgedCast(_ x: T, to: U.Type) -> U? { guard type(of: x) == U.self else { return nil } return unsafeBitCast(x, to: U.self) } > On Aug 24, 2016,

Re: [swift-evolution] Pitch: really_is and really_as operators

import Foundation let foo: Any = "Hello" type(of: foo) == String.self // true type(of: foo) == NSString.self // false let bar: Any = "Hello" as NSString type(of: bar) == String.self // false type(of: bar) == NSString.self // true Why not this? On Wed, Aug 24, 2016 at 19:09 Charles Srstka via

[swift-evolution] Pitch: really_is and really_as operators

MOTIVATION: SE-0083 appears to be dead in the water, having been deferred until later in Swift 3 back in May and not having been heard from since then, with the Swift 3 release looming closer and closer. However, the predictability gains that would have been provided by this change remain

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

I'd imagine an implementation something like this (but, in the bridging logic, not as a top level function…): func dynamicCast(_ array: [Any]) -> [T?] { var _type: CollectionCastType? func assertType(_ checkType: CollectionCastType) { guard let type = _type else {

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

First of all, I'm really happy with this proposal so far. I really appreciate the work that's been done to improve Swift and Objective-C interoperability. Now, question: Does this proposal also improve bridging from Objective-C to Swift or only the other direction? For example, let's say an

Re: [swift-evolution] Renaming for Protocol Conformance

> On 24 Aug 2016, at 20:38, Douglas Gregor via swift-evolution > wrote: > >> >> On Aug 22, 2016, at 9:59 PM, Jonathan Hull via swift-evolution >> > wrote: >> >> Hi everyone, >> >> We talked about this

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

> On Aug 24, 2016, at 11:29 AM, Tony Parker wrote: > >> >> On Aug 24, 2016, at 11:09 AM, Douglas Gregor > > wrote: >> >>> >>> On Aug 23, 2016, at 4:00 PM, Tony Parker >>

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

To be a little more clear, all I meant to point out was the difference between what originated as an abstract term and what is decidedly a concrete term. Everybody seems to have merged the two as a result of how the architecture evolved over time. My first degree was in English and that side of

Re: [swift-evolution] Renaming for Protocol Conformance

On Wed, Aug 24, 2016 at 1:59 PM, Jonathan Hull wrote: > > On Aug 24, 2016, at 7:48 AM, Xiaodi Wu wrote: > > On Wed, Aug 24, 2016 at 3:39 AM, Jonathan Hull wrote: > >> >> On Aug 23, 2016, at 8:35 AM, Xiaodi Wu wrote: >>

Re: [swift-evolution] Renaming for Protocol Conformance

> On Aug 24, 2016, at 11:38 AM, Douglas Gregor wrote: > >> >> On Aug 22, 2016, at 9:59 PM, Jonathan Hull via swift-evolution >> > wrote: >> >> Hi everyone, >> >> We talked about this before when we were

Re: [swift-evolution] [late pitch] UnsafeBytes proposal

> On Aug 23, 2016, at 9:56 PM, Chris Lattner via swift-evolution > wrote: > > >> On Aug 23, 2016, at 5:28 PM, Trent Nadeau via swift-evolution >> wrote: >> >> For an architecture to be C-compatible, its byte size must be 8 bits. Given

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

Hi Tim, After having a quick conversation with Dave, here is the question I should have asked right away: can you share the typical problem you are solving with your overload of the `sequence(first:next:)` function? Max > On Aug 20, 2016, at 2:26 AM, Tim Vermeulen wrote:

Re: [swift-evolution] Renaming for Protocol Conformance

> On Aug 24, 2016, at 7:48 AM, Xiaodi Wu wrote: > > On Wed, Aug 24, 2016 at 3:39 AM, Jonathan Hull > wrote: > >> On Aug 23, 2016, at 8:35 AM, Xiaodi Wu > > wrote: >> >> On Tue,

Re: [swift-evolution] Renaming for Protocol Conformance

> On Aug 22, 2016, at 9:59 PM, Jonathan Hull via swift-evolution > wrote: > > Hi everyone, > > We talked about this before when we were discussing mixins, and there seemed > to be generally positive feelings towards it as a feature for the future. I > am fairly

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

> On Aug 24, 2016, at 11:09 AM, Douglas Gregor wrote: > >> >> On Aug 23, 2016, at 4:00 PM, Tony Parker > > wrote: >> >> Hi Doug, >> >>> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

> On Aug 24, 2016, at 4:16 AM, David Rönnqvist > wrote: > > I have some problems understanding the scope of this proposal. More > specifically if it’s limited to arrays and dictionaries or if it’s broader > than that, and if it’s limited to objects that originate

Re: [swift-evolution] [Proposal draft] Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue

> On Aug 23, 2016, at 4:00 PM, Tony Parker wrote: > > Hi Doug, > >> On Aug 23, 2016, at 3:36 PM, Douglas Gregor via swift-evolution >> > wrote: >> >> Introduction >> >> A handful of Swift numeric types

Re: [swift-evolution] Keyword for protocol conformance

Requiring "override" when anything overrides a method defined in a protocol extension should be added - structure and enumerated included, of course. Protocol extensions added inheritance to structs and enums and this should be made explicit. Sent from my iPad > On Aug 24, 2016, at 12:55 AM,

Re: [swift-evolution] [Idea] Typed Numerics

Hi Vladimir, Your latest code is even nicer :) and works for most part, however found the following issues below: let dist : Distance = 10.km + 5.m + 5.mm let dist2 : Distance = 100.km + 5.m let weight : Weight = 10.pounds + 5.kg + 5.g // Assume we have Weight type defined also //let num =

Re: [swift-evolution] Renaming for Protocol Conformance

On Wed, Aug 24, 2016 at 3:39 AM, Jonathan Hull wrote: > > On Aug 23, 2016, at 8:35 AM, Xiaodi Wu wrote: > > On Tue, Aug 23, 2016 at 3:02 AM, Jonathan Hull wrote: > >> >> On Aug 22, 2016, at 11:32 PM, Xiaodi Wu wrote: >>

Re: [swift-evolution] [Pitch] Require Any for existentials

> On 24 Aug 2016, at 00:14, Adrian Zubarev via swift-evolution > wrote: > > The basic design is fine, but I wouldn't want to add more noise to my code. > We could keep (label: Protocol) as a shorthand form for (label: > Any) similar to Optionals. > > What's the

Re: [swift-evolution] [Pitch] Require Any for existentials

On 24.08.2016 13:23, Haravikk via swift-evolution wrote: On 23 Aug 2016, at 23:14, Adrian Zubarev via swift-evolution wrote: The basic design is fine, but I wouldn't want to add more noise to my code. We could keep (label: Protocol) as a shorthand form for (label:

Re: [swift-evolution] [Proposal draft] Bridge Optional As Its Payload Or NSNull

I have some problems understanding the scope of this proposal. More specifically if it’s limited to arrays and dictionaries or if it’s broader than that, and if it’s limited to objects that originate in Swift or if the same applies for objects that originate in Objective-C code. For me, it

Re: [swift-evolution] [Pitch] Require Any for existentials

> On 23 Aug 2016, at 23:14, Adrian Zubarev via swift-evolution > wrote: > > The basic design is fine, but I wouldn't want to add more noise to my code. > We could keep (label: Protocol) as a shorthand form for (label: > Any) similar to Optionals. > > What's the

Re: [swift-evolution] Renaming for Protocol Conformance

> On Aug 24, 2016, at 3:39 AM, Jonathan Hull via swift-evolution > wrote: > > To take your example of walk(). Perhaps we have a protocol ‘Walkable’ which > refers to any data structure where the nodes can be walked using the ‘walk()’ > function. It is easy to

Re: [swift-evolution] Renaming for Protocol Conformance

> On Aug 23, 2016, at 8:35 AM, Xiaodi Wu wrote: > > On Tue, Aug 23, 2016 at 3:02 AM, Jonathan Hull > wrote: > >> On Aug 22, 2016, at 11:32 PM, Xiaodi Wu > > wrote: >> >> On Mon,

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 24, 2016, at 1:20 AM, Robert Widmann wrote: > 2016/08/23 20:52、Charles Srstka > のメッセージ: > >>> On Aug 23, 2016, at 10:34 PM, Robert Widmann >>

Re: [swift-evolution] Keyword for protocol conformance

~Robert Widmann 2016/08/23 20:52、Charles Srstka のメッセージ: >> On Aug 23, 2016, at 10:34 PM, Robert Widmann >> wrote: >> >> 2016/08/23 15:29、Charles Srstka のメッセージ: >> On Aug 23, 2016, at 2:33 PM, Robert