Re: [swift-evolution] Mark protocol methods with their protocol

I would like to make it a requirement if not inside a protocol extension which declares a conformance, and actually build the protocol name in to the member in an ABI-breaking way. We could make it additive by generating forwarding thunks from the old symbols to the new ones, but it would be

Re: [swift-evolution] Mark protocol methods with their protocol

> On Sep 20, 2016, at 4:34 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Sep 20 2016, Karl wrote: > >> I think the best way is to prefix the member name with the protocol, e.g: >> >> protocol MyProto { >>var aVariable : Int >>func

Re: [swift-evolution] Should Swift apply "statement scope" for ARC

> On Sep 21, 2016, at 4:01 PM, John Holdsworth wrote: > > My contrived example was a bit flimsy. I’d better unpack the full story. The > real > code I had problems with was based around the following Java instance wrapper: > > open class JNIObject: JNIObjectProtocol {

Re: [swift-evolution] Should Swift apply "statement scope" for ARC

My contrived example was a bit flimsy. I’d better unpack the full story. The real code I had problems with was based around the following Java instance wrapper: open class JNIObject: JNIObjectProtocol { var _javaObject: jobject? open var javaObject: jobject? { get {

Re: [swift-evolution] Should Swift apply "statement scope" for ARC

> On Sep 21, 2016, at 3:14 PM, Xiaodi Wu via swift-evolution > wrote: > > I haven't used it myself, but is this the use case addressed by > `withExtendedLifetime(_:_:)`? Yeah, if you want to vend resources managed by an object to consumers outside of that object

Re: [swift-evolution] Should Swift apply "statement scope" for ARC

I haven't used it myself, but is this the use case addressed by `withExtendedLifetime(_:_:)`? On Wed, Sep 21, 2016 at 16:54 John Holdsworth via swift-evolution < swift-evolution@swift.org> wrote: > Hi, > > For complex statements in C++ any temporary instances created in the course > of an

[swift-evolution] Should Swift apply "statement scope" for ARC

Hi, For complex statements in C++ any temporary instances created in the course of an expression have their lifetime extended to the completion of the current statement after which they are all deallocated en masse. This makes certain types of language usage possible and easier to reason with.

Re: [swift-evolution] [Pre-Review] Permit where clauses to constrain associated types

I… like this syntax but I have to admit that I am confused about ```protocol IntSequence : Sequence where Iterator.Element == Int { ... } ``` I think that this example needs a better subtype/subprotocol to motivate the feature. This particular type seems more like a constrained typealias

[swift-evolution] [Pre-Review] Permit where clauses to constrain associated types

Hello mailing list, Since the following proposal was discussed before the release of Swift 3 and then delayed, I’m opening it up again for a short pre-review before to get some additional feedback before it can be merged. Web link:

Re: [swift-evolution] Bls: Range that goes both ways

> On 21 Sep 2016, at 11:44, Mr Bee via swift-evolution > wrote: > > > But after I thought about it again, I think half-opened range doesn't really > make any senses. The ..< operator (and my proposed ..> operator) should be > removed. Or we have to accept the

Re: [swift-evolution] Testing access level, final, and static

on Wed Sep 21 2016, Benjamin Spratling wrote: > Howdy, > As I understand it, In Swift 3, a lack of encapsulation is testable, > but specific keywords to protect a designed encapsulation can’t be > introspected, and thus encapsulation is fragile, i.e. not protectable >

Re: [swift-evolution] Mark protocol methods with their protocol

On 21.09.2016 2:34, Dave Abrahams via swift-evolution wrote: on Tue Sep 20 2016, Karl wrote: I think the best way is to prefix the member name with the protocol, e.g: protocol MyProto { var aVariable : Int func aFunction() } class MyClass : MyProto { var MyProto.aVariable : Int

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

On 21.09.2016 9:30, Goffredo Marocchi via swift-evolution wrote: If the reference to the instance of the class is cast to the protocol type, I want other object to be aware of my API contract not the specific class instance, then the protocol default method gets called and that is several shades

[swift-evolution] Testing access level, final, and static

Howdy, As I understand it, In Swift 3, a lack of encapsulation is testable, but specific keywords to protect a designed encapsulation can’t be introspected, and thus encapsulation is fragile, i.e. not protectable by unit tests. For instance, we can write unit-tests that determine if a member's

Re: [swift-evolution] Range that goes both ways

Hi, AFAIK, these all would be very much sugar for: 1) (1 ..< 5).reversed() 2) The same as above: (1 ... 5).reversed() does exactly what you want. 3) Kind of makes sense to me to include >.., though to be thorough, you'd need to add >.< as well - that's a weird looking operator... 4) There's a

[swift-evolution] Range that goes both ways

Hi, I'm a Swift newbie so forgive me if my question sounds a bit silly, or perhaps had been asked previously. My question is, why Swift doesn't have built-in operator for backward or decremented range? Especially to be used in for-in loop. Swift only has ... (closed range) and ..< (half-opened

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

Sent from my iPhone > On 21 Sep 2016, at 01:41, Zhao Xin wrote: > > > I am not sure why protocol extension need to differ so much and present > > dispatch rules that are potentially very confusing. > > I think that both the Java and Swift designers want to get the benefits