Re: [swift-evolution] Keyword for protocol conformance

On Thu, Aug 25, 2016 at 11:05 PM, Charles Srstka wrote: > On Aug 25, 2016, at 10:24 PM, Xiaodi Wu wrote: > > > Yes, and it's covered in those previous threads. In brief, not all > retroactive modeling involves extending a type: > > * A vendor

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 25, 2016, at 10:24 PM, Xiaodi Wu wrote: > > Yes, and it's covered in those previous threads. In brief, not all > retroactive modeling involves extending a type: > > * A vendor supplies you with a closed-source library with a struct S that > conforms to standard

Re: [swift-evolution] Keyword for protocol conformance

Yes, and it's covered in those previous threads. In brief, not all retroactive modeling involves extending a type: * A vendor supplies you with a closed-source library with a struct S that conforms to standard library protocol P. * Protocol P requires a method named foo(), so struct S has its

Re: [swift-evolution] Keyword for protocol conformance

Is there a reason that adding a “retro” keyword on extensions meant to retroactively apply a protocol is unacceptable? Charles > On Aug 25, 2016, at 6:44 PM, Xiaodi Wu via swift-evolution > wrote: > > Chris, as I wrote above, this idea has been discussed previously

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

On Thu, Aug 25, 2016 at 17:08 Vladimir.S via swift-evolution < swift-evolution@swift.org> wrote: > > The behavior is due to the Objective-C bridge, which I don’t think > exists > > on the Linux version. On the Mac version, fooIsNSString will be true > > because of the bridging magic that lets

Re: [swift-evolution] Keyword for protocol conformance

Chris, as I wrote above, this idea has been discussed previously on several occasions, and the principal reason why it has been abandoned each time is that it cannot accommodate retroactive modeling. I'll refer you again to three previous threads discussing this and closely related matters:

Re: [swift-evolution] Keyword for protocol conformance

If we really want to be overkill, we could use `required` for implementing an un-defaulted protocol requirement, `override` for implementing a defaulted protocol requirement, and `default` for implementing a protocol requirement in a protocol extension. I think this might be more verbose than

Re: [swift-evolution] Keyword for protocol conformance

> On Aug 25, 2016, at 4:32 PM, Christopher Kornher wrote: > > I hope that my brief email wasn’t the final word on this :( > > Does anyone think that a proposal to require “override” for overrides of > protocol extension methods and variables (?) would be worth exploring? > >

Re: [swift-evolution] Keyword for protocol conformance

I hope that my brief email wasn’t the final word on this :( Does anyone think that a proposal to require “override” for overrides of protocol extension methods and variables (?) would be worth exploring? This would address a number of the issues raised in this thread, but not all. My intention

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

> The behavior is due to the Objective-C bridge, which I don’t think exists > on the Linux version. On the Mac version, fooIsNSString will be true > because of the bridging magic that lets you convert between String and > NSString (and other equivalent Swift and Objective-C data types) using >

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

> On Aug 25, 2016, at 4:15 PM, Vladimir.S via swift-evolution > wrote: > > > let fooIsNSString = foo is NSString // true > > I don't understand. Why is so? On which version of Swift did you try this? > > IBM Swift Sandbox > Swift Ver. 3.0 (Aug 23, 2016) >

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

I believe that due to SE-0072 my code(Swift Ver. 3.0 (Aug 23, 2016) on Linux) is working right, no? On 26.08.2016 0:18, Adrian Zubarev via swift-evolution wrote: Tested with Swift 3.0 Xcode 8 beta 6 playground. -- Adrian Zubarev Sent with Airmail Am 25. August 2016 um 23:15:24, Vladimir.S

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

Tested with Swift 3.0 Xcode 8 beta 6 playground. --  Adrian Zubarev Sent with Airmail Am 25. August 2016 um 23:15:24, Vladimir.S (sva...@gmail.com) schrieb: > let fooIsNSString = foo is NSString // true I don't understand. Why is so? On which version of Swift did you try this? IBM Swift

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

> let fooIsNSString = foo is NSString // true I don't understand. Why is so? On which version of Swift did you try this? IBM Swift Sandbox Swift Ver. 3.0 (Aug 23, 2016) Platform: Linux (x86_64) import Foundation let foo: Any = "Foo" let bar: Any = NSString(string: "Bar") let

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

on Mon Aug 22 2016, Félix Cloutier wrote: > I remember that the conclusion for type-safe unit calculations was > that we didn't want to implement it as a compiler feature, but rather > implement compiler features that would make it possible (as it is in > C++

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

> On Aug 25, 2016, at 11:56 AM, Xiaodi Wu wrote: > > On Thu, Aug 25, 2016 at 11:28 AM, Matthew Johnson > wrote: > >> On Aug 25, 2016, at 11:15 AM, Xiaodi Wu > >

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

Is that what you guys wanted to achieve? @inline(never) func opaqueCast(_ x: T, _: U.Type) -> Bool { return x is U } let foo: Any = "Foo" let bar: Any = NSString(string: "Bar") let fooIsString = foo is String // true opaqueCast(type(of: foo), String.Type.self) // true

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

> On Aug 25, 2016, at 2:29 AM, Karl via swift-evolution > wrote: > This is not a new inconsistency. We’ve known about this since “open” was > first proposed. > > Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. Everything is too late for

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

On Thu, Aug 25, 2016 at 11:28 AM, Matthew Johnson wrote: > > On Aug 25, 2016, at 11:15 AM, Xiaodi Wu wrote: > > On Thu, Aug 25, 2016 at 10:07 AM, Matthew Johnson > wrote: > >> >> On Aug 25, 2016, at 9:37 AM, Xiaodi Wu

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

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

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

On Thu, Aug 25, 2016 at 10:07 AM, Matthew Johnson wrote: > > On Aug 25, 2016, at 9:37 AM, Xiaodi Wu wrote: > > Charles clarified that indeed he was pitching casting operators that match > subclasses. > > > Ok, I missed that. > > > If the compiler

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

Syntax for `T == P || T: P` is off-topic for current proposal, which is just about replacing `P` with `Any`. Currently, equivalent of `Any` has no subtypes (besides itself). This is likely not going to be changed. So `where U : Any` will not be allowed. Generalized existentials also don't solve

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

> On Aug 25, 2016, at 9:37 AM, Xiaodi Wu wrote: > > Charles clarified that indeed he was pitching casting operators that match > subclasses. Ok, I missed that. > > If the compiler knows that a class is sealed, why do you think there's a new > keyword needed for the

Re: [swift-evolution] InternalString class for easy String manipulation

on Sun Aug 14 2016, Michael Savich wrote: > Back in Swift 1.0, subscripting a String was easy, you could just use > subscripting in a very Python like way. Just to correct the record: no, it was really never like that in Swift. -- -Dave

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

on Sun Aug 14 2016, Tim Vermeulen wrote: > sequence(first:next:) takes a non-optional first argument. Is there a > reason for that? Yes; it's understandable and fits many common use cases. > sequence(state:next:) allows empty sequences, and I don’t see why >

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

Charles clarified that indeed he was pitching casting operators that match subclasses. If the compiler knows that a class is sealed, why do you think there's a new keyword needed for the compiler to prove exhaustiveness? First, you can already match exact types by writing `type(of: instance) ==

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

> On Aug 24, 2016, at 9:33 PM, Xiaodi Wu wrote: > > On Wed, Aug 24, 2016 at 9:25 PM, Matthew Johnson via swift-evolution > > wrote: > >> On Aug 24, 2016, at 9:09 PM, Robert Widmann via swift-evolution >>

Re: [swift-evolution] [Idea] Add `bounds` function to standard library

> On 25 Aug 2016, at 12:05, Nicholas Maccharoli wrote: > > I personally see merit in adding a function to bound the value of a variable > within a range and think it would be simple to write with the existing > implementations of `min` and `max` with something like: > > public func

[swift-evolution] [Idea] Add `bounds` function to standard library

> In the standard library there is a `min` and a `max` function but there isn't > a `bounds` function, or a function that takes a value and an upper and lower > bound and returns that value if it is Perhaps ‘clamp’ would be a better name? ___

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

This is not a new inconsistency. We’ve known about this since “open” was first proposed. Having sealed protocols would be nice, but it’s too late for Swift 3 IMO. Karl > On 22 Aug 2016, at 20:40, Adrian Zubarev via swift-evolution > wrote: > > Hello dear Swift

[swift-evolution] [Idea] Add `bounds` function to standard library

Swift Evolution Community, In the standard library there is a `min` and a `max` function but there isn't a `bounds` function, or a function that takes a value and an upper and lower bound and returns that value if it is within the specified range or if not the closer of the lower or upper values