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

> On 17 Sep 2016, at 05:32, Xiaodi Wu wrote: > > On Fri, Sep 16, 2016 at 20:28 Karl > wrote: >> On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution >> >

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

On Fri, Sep 16, 2016 at 20:28 Karl wrote: > On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > I absolutely agree that it's a problem worth solving. However, the > question is whether a particular proposed design solves the

[swift-evolution] Should closures support inout parameters?

I was writing some code that would allow transformations of values as part of an expression, and I came across a strange error: /// Returns the operand after a given transformation. /// /// Example: `let newRect = myRect << { $0.origin.x += 3 }` func << (given: T, transformation: (inout T) ->

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

> On 17 Sep 2016, at 01:45, Xiaodi Wu via swift-evolution > wrote: > > I absolutely agree that it's a problem worth solving. However, the question > is whether a particular proposed design solves the problem and avoids > previously stated weaknesses. What I'm

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

I'm not familiar with all of the discussions in other threads relating to this issue that some are here, so forgive me if I'm running over old ground. Looking back at the original use case that David B. posted my first instinct was that this is a case that would best be solved by adding a

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

Yeah, I figured it had probably come up before since I don’t follow evolution that closely, but it is, in my opinion and experience, Swift’s last pitfall. So many other pitfalls from ObjC and other languages have been solved with Swift, including this exact one (when it comes to subclassing).

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

On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution wrote: > > We've had this discussion on the list multiple times already. The gist of the > difficulty here is that most proposals for a mandatory keyword don't permit > retroactive modeling, so it's a no-go.

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

We've had this discussion on the list multiple times already. The gist of the difficulty here is that most proposals for a mandatory keyword don't permit retroactive modeling, so it's a no-go. On the other hand, the core team seems to take a dim view to optional syntax, since that's more in the

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

I don’t really like the idea of override(ProtocolName), but I’d support the single override here. On value types it’s easier to recognize the member of a protocol which had a default implementation. I don’t feel like adding override to all members that replaces some default implementation will

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

David, thank you for a real-word example when such feature will be very useful and can protect from hard-to-find bugs. IMO This shows that we should find a solution for the problem as soon as possible. Such or similar question was discussed already in an number of threads, for example in

Re: [swift-evolution] Tuples as Named Types

~Robert Widmann 2016/09/16 10:03、Muhammad Tahir Vali のメッセージ: > Type safety would make tuples far more powerful than their current > limitations. Tuples, like every other language construct in Swift are typed. If you find a situation where they aren't, please let us

Re: [swift-evolution] Tuples as NominalTypes

Hello Muhammad, I am not exactly sure what you are after with this or your previous post about tuples. Tuples are 'type safe' for any definition of 'type safety' that I can summon. Switching over tuples to restructure them is, in my opinion, a main source of the type safety provided in tuples. I

[swift-evolution] Tuples as NominalTypes

Type safety would make tuples far more powerful than their current limitations. Structs are usually used for slightly more complex objects compared to tuples and usually, you need them longer in memory. Tuples are just for quick manipulation. Since you are interested in just the content inside,