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

[Karl via swift-evolution]

> 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 
>> > 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 saying here is that, so far, the 
>> conversation in this thread has involved reiterating already-proposed 
>> designs that have been critiqued. It's really quite tiring for me too to 
>> repeat the same critique when someone raises the same proposal a second or 
>> third time.
>> 
>> It's possible that it makes sense to have a separate syntax for retroactive 
>> modeling. I haven't been able to come up with one that seems reasonable to 
>> me, or I would have written to this list to propose it. Do you have such a 
>> design in mind?
>> On Fri, Sep 16, 2016 at 16:59 Charles Srstka > > wrote:
>> 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. On the other hand, the core 
>>> team seems to take a dim view to optional syntax, since that's more in the 
>>> ballpark of linters.
>> 
>> Numerous solutions to your objection have been proposed; you always simply 
>> dismiss all of them in favor of your dogmatic stance. It’s really quite 
>> tiring. You can have this and support retroactive modeling; you just might 
>> need to have a separate syntax for retroactive conformances. You keep 
>> bringing that up as a hard-and-fast objection, but you know what? Maybe 
>> retroactive conformances should have a separate syntax, because they’re not 
>> saying the same thing! One is saying "here are some methods that will make 
>> this type conform to this protocol”, where the other is saying “this type 
>> already has the methods that conform to this protocol somewhere.” These are 
>> not the same thing, and it might be confusing to see a conformance 
>> declaration and assume it’s the former when it’s actually the latter, and 
>> then have trouble finding the conformances. Maybe it would actually make 
>> your code clearer if retroactive conformances were required to declare “this 
>> method exists somewhere else already.” Maybe you could even command-click on 
>> it and jump to the actual declaration. Anything would be better than the 
>> current situation, because:
>> 
>> The reason this keeps coming up is because it’s a real problem. I myself 
>> have started taking up the practice of always using copy-and-paste to 
>> declare conformances to protocols, because otherwise the chances of 
>> mistyping something and having the bug not manifest itself until runtime is 
>> simply too high. This is not a “linter” problem; this affects basic 
>> functionality and makes protocols, honestly, really dangerous to use. For a 
>> language that bills itself as “protocol-oriented”, it’s really quite damning 
>> that its protocol support is this brittle and fragile compared to its 
>> support for traditional inheritance. I’ve been bitten by this enough times 
>> by now to somewhat regret the decision to go with a protocol-based design. 
>> This is a real shame because conceptually, the idea of Swift’s 
>> protocol-based design is really cool.
>> 
>> Charles
>> 
> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
> 
> I don’t see what the big problem about retroactive modelling is.
> 
> Let me give a concrete example of how retroactively modeling is used. 
> Currently, there is a JIRA bug that Set does not conform to SetAlgebra. To 
> fix this issue, someone simply needs to write `extension Set : SetAlgebra { 
> }` and some tests. That's literally what the bug (filed by a core team 
> member) tells you to do. It's a starter bug, and if someone hasn't taken it 
> yet, you the reader could have a go at it. What's neat about Swift is that 
> it's super easy to provide the same functionality in your own project without 
> waiting on that bug to be fixed in Swift itself. You can simply write a 
> single line of code. By contrast, if your proposal were to be implemented, 
> this would become much more difficult.
> 
> This is actively used in Swift today. For example, in the Swift 
> implementation of NSScanner, you'll find the following lines:
> 
> ```
> internal protocol 

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

[Xiaodi Wu via swift-evolution]

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 problem and
> avoids previously stated weaknesses. What I'm saying here is that, so far,
> the conversation in this thread has involved reiterating already-proposed
> designs that have been critiqued. It's really quite tiring for me too to
> repeat the same critique when someone raises the same proposal a second or
> third time.
>
> It's possible that it makes sense to have a separate syntax for
> retroactive modeling. I haven't been able to come up with one that seems
> reasonable to me, or I would have written to this list to propose it. Do
> you have such a design in mind?
> On Fri, Sep 16, 2016 at 16:59 Charles Srstka 
> wrote:
>
>> On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via swift-evolution <
>> swift-evolution@swift.org> 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. On the other hand, the core
>> team seems to take a dim view to optional syntax, since that's more in the
>> ballpark of linters.
>>
>>
>> Numerous solutions to your objection have been proposed; you always
>> simply dismiss all of them in favor of your dogmatic stance. It’s really
>> quite tiring. You can have this and support retroactive modeling; you just
>> might need to have a separate syntax for retroactive conformances. You keep
>> bringing that up as a hard-and-fast objection, but you know what? Maybe
>> retroactive conformances *should* have a separate syntax, because
>> they’re not saying the same thing! One is saying "here are some methods
>> that will make this type conform to this protocol”, where the other is
>> saying “this type already has the methods that conform to this protocol
>> somewhere.” These are not the same thing, and it might be confusing to see
>> a conformance declaration and assume it’s the former when it’s actually the
>> latter, and then have trouble finding the conformances. Maybe it would
>> actually make your code clearer if retroactive conformances were required
>> to declare “this method exists somewhere else already.” Maybe you could
>> even command-click on it and jump to the actual declaration. Anything would
>> be better than the current situation, because:
>>
>> The reason this keeps coming up is because it’s a real problem. I myself
>> have started taking up the practice of always using copy-and-paste to
>> declare conformances to protocols, because otherwise the chances of
>> mistyping something and having the bug not manifest itself until runtime is
>> simply too high. This is not a “linter” problem; this affects basic
>> functionality and makes protocols, honestly, really dangerous to use. For a
>> language that bills itself as “protocol-oriented”, it’s really quite
>> damning that its protocol support is this brittle and fragile compared to
>> its support for traditional inheritance. I’ve been bitten by this enough
>> times by now to somewhat regret the decision to go with a protocol-based
>> design. This is a real shame because conceptually, the idea of Swift’s
>> protocol-based design is really cool.
>>
>> Charles
>>
>> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> I don’t see what the big problem about retroactive modelling is.
>

Let me give a concrete example of how retroactively modeling is used.
Currently, there is a JIRA bug that Set does not conform to SetAlgebra. To
fix this issue, someone simply needs to write `extension Set : SetAlgebra {
}` and some tests. That's literally what the bug (filed by a core team
member) tells you to do. It's a starter bug, and if someone hasn't taken it
yet, you the reader could have a go at it. What's neat about Swift is that
it's super easy to provide the same functionality in your own project
without waiting on that bug to be fixed in Swift itself. You can simply
write a single line of code. By contrast, if your proposal were to be
implemented, this would become much more difficult.

This is actively used in Swift today. For example, in the Swift
implementation of NSScanner, you'll find the following lines:

```
internal protocol _BitShiftable {
static func >>(lhs: Self, rhs: Self) -> Self
static func <<(lhs: Self, rhs: Self) -> Self
}

internal protocol _IntegerLike : Integer, _BitShiftable {
init(_ value: Int)
static var max: Self { get }
static var min: Self { get }
}

extension Int : _IntegerLike { }
extension Int32 : _IntegerLike { }
extension Int64 : _IntegerLike { }
extension UInt32 : _IntegerLike { }
extension 

[swift-evolution] Should closures support inout parameters?

[Braeden Profile via swift-evolution]

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) -> ()) -> T
{
var result = given
transformation()
return result
}

let volume = component.volume << { $0.ranges.z.width = 0 } // Error:  
Expression type () is ambiguous without more context.
let volume = component.volume << { $0.ranges.z.width = 0; return () } // Error: 
 Cannot assign to property: ‘$0’ is immutable.
let volume = component.volume << { (x: inout SCNBoxVolume) in x.ranges.z.width 
= 0 } // Succeeds!


Obviously, this code could easily create a var for volume and mutate it, but it 
doesn’t solve my problem.  Am I misunderstanding how this could work?  This is 
the only overload of << that accepts a closure, and even the code completion 
recognizes that $0 is a SCNBoxVolume.  It’s just strange that the compiler 
won’t recognize $0 as an inout parameter off the bat.

Is this a bug, or a design choice?

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Karl via swift-evolution]

> 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 saying here is that, so far, the 
> conversation in this thread has involved reiterating already-proposed designs 
> that have been critiqued. It's really quite tiring for me too to repeat the 
> same critique when someone raises the same proposal a second or third time.
> 
> It's possible that it makes sense to have a separate syntax for retroactive 
> modeling. I haven't been able to come up with one that seems reasonable to 
> me, or I would have written to this list to propose it. Do you have such a 
> design in mind?
> On Fri, Sep 16, 2016 at 16:59 Charles Srstka  > wrote:
> 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. On the other hand, the core 
>> team seems to take a dim view to optional syntax, since that's more in the 
>> ballpark of linters.
> 
> Numerous solutions to your objection have been proposed; you always simply 
> dismiss all of them in favor of your dogmatic stance. It’s really quite 
> tiring. You can have this and support retroactive modeling; you just might 
> need to have a separate syntax for retroactive conformances. You keep 
> bringing that up as a hard-and-fast objection, but you know what? Maybe 
> retroactive conformances should have a separate syntax, because they’re not 
> saying the same thing! One is saying "here are some methods that will make 
> this type conform to this protocol”, where the other is saying “this type 
> already has the methods that conform to this protocol somewhere.” These are 
> not the same thing, and it might be confusing to see a conformance 
> declaration and assume it’s the former when it’s actually the latter, and 
> then have trouble finding the conformances. Maybe it would actually make your 
> code clearer if retroactive conformances were required to declare “this 
> method exists somewhere else already.” Maybe you could even command-click on 
> it and jump to the actual declaration. Anything would be better than the 
> current situation, because:
> 
> The reason this keeps coming up is because it’s a real problem. I myself have 
> started taking up the practice of always using copy-and-paste to declare 
> conformances to protocols, because otherwise the chances of mistyping 
> something and having the bug not manifest itself until runtime is simply too 
> high. This is not a “linter” problem; this affects basic functionality and 
> makes protocols, honestly, really dangerous to use. For a language that bills 
> itself as “protocol-oriented”, it’s really quite damning that its protocol 
> support is this brittle and fragile compared to its support for traditional 
> inheritance. I’ve been bitten by this enough times by now to somewhat regret 
> the decision to go with a protocol-based design. This is a real shame because 
> conceptually, the idea of Swift’s protocol-based design is really cool.
> 
> Charles
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


I don’t see what the big problem about retroactive modelling is.

Basically, the way I see it, if my class MyClass implements MyProtocol, 
providing someRequiredFunc(), there’s an “ownership” chain there (reading it 
backwards).

Now what happens if MyClass implements MyOtherProtocol, which also has 
someRequiredFunc()? In that case, I want to MyClass as a MyOtherProtocol and 
get another function pointer, which just happens to have the same 
human-readable name as some other property. Just because they have the same 
function signature, absolutely doesn’t mean they’re the same thing.

Now, if we strongly bind all protocol conformances to the protocol they 
implement, what happens to instance methods? They don’t belong to any protocol, 
their parent is the class itself. If you have an instance method called 
someRequiredFunc(), and you later add a conformance to MyProtocol, you would 
need to declare that it belongs to MyProtocol. If you don’t want it to be an 
API-breaking change, you have to provide a thunk (or we could provide a 
shorthand syntax which emits thunks for you) to let us know that 
MyClass::someRequiredFunc() is the same thing as 
MyClass::MyProtocol::someRequiredFunc().

Let’s take an example where retroactive modelling could go wrong. You’ve got 
different teams working on different parts of an App, and they’ve 

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

[David Goodine via swift-evolution]

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 compiler 
warning/error based on any function signature that matches a protocol signature 
but differs in the types.

My opinion is that naming a function that is so similar to a protocol function 
but clearly has a different signature is a bad idea and at least should be a 
warning. If Swift wants to be opinionated about it, it could become an error.

But looking at Vladimir's response, one thing that caught my interest was the 
idea of an 'implements' keyword. I think it might be a good addition to the 
language because it a) avoids this whole class of programming mistakes and, 
more importantly, b) strengthens the 'intention' of the programmer implementing 
the protocol, similarly to the way 'override' works for inherited functions.

One of the things I really like about Swift is that in many cases it requires 
programmers to explicitly state their intent when writing code (i.e. override). 
I think Vladimir's suggestion could do the same for protocols and should be 
considered. 

Sent from my iPhone

> On Sep 16, 2016, at 6:28 PM, David Beck via swift-evolution 
>  wrote:
> 
> 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). If we are 
> going to say that it is a big enough problem to solve with a language feature 
> for subclasses, it really seems like it would make sense to solve it for 
> protocol conformance.
> 
> > On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via 
> > swift-evolutionwrote:
> > > 
> > > 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 ballpark of linters.
> > Numerous solutions to your objection have been proposed; you always simply 
> > dismiss all of them in favor of your dogmatic stance. It’s really quite 
> > tiring. You can have this and support retroactive modeling; you just might 
> > need to have a separate syntax for retroactive conformances. You keep 
> > bringing that up as a hard-and-fast objection, but you know what? Maybe 
> > retroactive conformancesshouldhave a separate syntax, because they’re not 
> > saying the same thing! One is saying "here are some methods that will make 
> > this type conform to this protocol”, where the other is saying “this type 
> > already has the methods that conform to this protocol somewhere.” These are 
> > not the same thing, and it might be confusing to see a conformance 
> > declaration and assume it’s the former when it’s actually the latter, and 
> > then have trouble finding the conformances. Maybe it would actually make 
> > your code clearer if retroactive conformances were required to declare 
> > “this method exists somewhere else already.” Maybe you could even 
> > command-click on it and jump to the actual declaration. Anything would be 
> > better than the current situation, because:
> > 
> > The reason this keeps coming up is because it’s a real problem. I myself 
> > have started taking up the practice of always using copy-and-paste to 
> > declare conformances to protocols, because otherwise the chances of 
> > mistyping something and having the bug not manifest itself until runtime is 
> > simply too high. This is not a “linter” problem; this affects basic 
> > functionality and makes protocols, honestly, really dangerous to use. For a 
> > language that bills itself as “protocol-oriented”, it’s really quite 
> > damning that its protocol support is this brittle and fragile compared to 
> > its support for traditional inheritance. I’ve been bitten by this enough 
> > times by now to somewhat regret the decision to go with a protocol-based 
> > design. This is a real shame because conceptually, the idea of Swift’s 
> > protocol-based design is really cool.
> > 
> > Charles
> > 
> > 
> > 
> >  
> 
> 
> David Beck
> http://davidbeck.co
> http://twitter.com/davbeck
> http://facebook.com/davbeck
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Beck via swift-evolution]

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). If we are going to say 
that it is a big enough problem to solve with a language feature for 
subclasses, it really seems like it would make sense to solve it for protocol 
conformance.

> On Sep 16, 2016, at 4:08 PM, Xiaodi Wu via 
> swift-evolutionwrote:
> > 
> > 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 
> > ballpark of linters.
> Numerous solutions to your objection have been proposed; you always simply 
> dismiss all of them in favor of your dogmatic stance. It’s really quite 
> tiring. You can have this and support retroactive modeling; you just might 
> need to have a separate syntax for retroactive conformances. You keep 
> bringing that up as a hard-and-fast objection, but you know what? Maybe 
> retroactive conformancesshouldhave a separate syntax, because they’re not 
> saying the same thing! One is saying "here are some methods that will make 
> this type conform to this protocol”, where the other is saying “this type 
> already has the methods that conform to this protocol somewhere.” These are 
> not the same thing, and it might be confusing to see a conformance 
> declaration and assume it’s the former when it’s actually the latter, and 
> then have trouble finding the conformances. Maybe it would actually make your 
> code clearer if retroactive conformances were required to declare “this 
> method exists somewhere else already.” Maybe you could even command-click on 
> it and jump to the actual declaration. Anything would be better than the 
> current situation, because:
> 
> The reason this keeps coming up is because it’s a real problem. I myself have 
> started taking up the practice of always using copy-and-paste to declare 
> conformances to protocols, because otherwise the chances of mistyping 
> something and having the bug not manifest itself until runtime is simply too 
> high. This is not a “linter” problem; this affects basic functionality and 
> makes protocols, honestly, really dangerous to use. For a language that bills 
> itself as “protocol-oriented”, it’s really quite damning that its protocol 
> support is this brittle and fragile compared to its support for traditional 
> inheritance. I’ve been bitten by this enough times by now to somewhat regret 
> the decision to go with a protocol-based design. This is a real shame because 
> conceptually, the idea of Swift’s protocol-based design is really cool.
> 
> Charles
> 
> 
> 
>  


David Beck
http://davidbeck.co
http://twitter.com/davbeck
http://facebook.com/davbeck

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Charles Srstka via swift-evolution]

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. On the other hand, the core team seems 
> to take a dim view to optional syntax, since that's more in the ballpark of 
> linters.

Numerous solutions to your objection have been proposed; you always simply 
dismiss all of them in favor of your dogmatic stance. It’s really quite tiring. 
You can have this and support retroactive modeling; you just might need to have 
a separate syntax for retroactive conformances. You keep bringing that up as a 
hard-and-fast objection, but you know what? Maybe retroactive conformances 
should have a separate syntax, because they’re not saying the same thing! One 
is saying "here are some methods that will make this type conform to this 
protocol”, where the other is saying “this type already has the methods that 
conform to this protocol somewhere.” These are not the same thing, and it might 
be confusing to see a conformance declaration and assume it’s the former when 
it’s actually the latter, and then have trouble finding the conformances. Maybe 
it would actually make your code clearer if retroactive conformances were 
required to declare “this method exists somewhere else already.” Maybe you 
could even command-click on it and jump to the actual declaration. Anything 
would be better than the current situation, because:

The reason this keeps coming up is because it’s a real problem. I myself have 
started taking up the practice of always using copy-and-paste to declare 
conformances to protocols, because otherwise the chances of mistyping something 
and having the bug not manifest itself until runtime is simply too high. This 
is not a “linter” problem; this affects basic functionality and makes 
protocols, honestly, really dangerous to use. For a language that bills itself 
as “protocol-oriented”, it’s really quite damning that its protocol support is 
this brittle and fragile compared to its support for traditional inheritance. 
I’ve been bitten by this enough times by now to somewhat regret the decision to 
go with a protocol-based design. This is a real shame because conceptually, the 
idea of Swift’s protocol-based design is really cool.

Charles

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Xiaodi Wu via swift-evolution]

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
ballpark of linters.

I really don't see anything new here that we haven't already discussed at
length...


On Fri, Sep 16, 2016 at 15:25 Adrian Zubarev via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 break anything. Furthermore, I’d love to see
> the addition where we could call the default implementation.
>
> Here is some bikeshedding:
>
> protocol A {}
>
> extension A {
>func foo() { .. }
> }
>
> protocol B : A {}
>
> extension B {
>// overriding default implementation from an other one!?
>override func foo() {
> // call default implementation of A
>default.foo()
> }
> }
>
> struct C : A {
>// overriding some default implementation
>override func foo() {
>   // call default implementation
>default.foo()
> }
> }
>
> struct D : B {
>   // overriding some default implementation
>override func foo() {
>   // call default implementation B
>   // which will also call default implementation of A
>default.foo()
> }
> }
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 16. September 2016 um 20:45:05, Vladimir.S via swift-evolution (
> swift-evolution@swift.org) schrieb:
>
> 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 "Requiring proactive overrides for default protocol
> implementations." and in "Requiring special keyword to mark protocol
> implementation methods", probably in other threads also.
>
> The first is that `override` is not used in structs, so IMO it will be
> alien here.
> Second, if protocol has no default implementation for the method- would
> you
> require the `override(Protocol)` also?
>
> Then, in case you will not require a keyword when no default
> implementation
> - you should think about retrospective adding of extension.
>
> I.e. imagine, you have a source file, let's call it SomeClass.swift which
> you can't or don't want to change(this could be some complex source from
> 3rd party, from github, or from other developer of your company). This
> file
> compiles without problems. It contains:
>
> public protocol Foo { func foo() }
> public class Some: Foo { func foo() {...} }
>
> You added SomeClass.swift to your project and in your My.swift you added
> default implementation for Foo protocol:
>
> extension Foo { func foo() {...} }
>
> So, now, when you compile your project, there is default implementation
> for
> foo() and class Some should contains `override(Foo)`, but you can't change
> SomeClass.swift.
>
>
> The only solution I see here, is if this `override(Foo)` will be optional,
> and just express developer's intention, if he/she wants this. I.e. it is
> not required, but if you specify it - compiler will check this intention.
> But AFAIR unfortunately someone from core team mentioned that they don't
> want such optional solution.
>
> And, at the end, I do think the real reason of your problem is not that
> protocol method has default implementation, but that
> `viewController(with:properties:)` definition in `FooController` does not
> say for compiler(and compiler does not check this) that this method was
> defined *exactly* to confirm to protocol. I.e. you can't clearly express
> your intention regarding why this method is here. Check this example:
>
> Let's assume you defined protocol Foo in FooProto.swift file:
>
> public protocol Foo { func foo() }
>
> and have class `Some` conformed to Foo in SomeClass.swift:
>
> public class Some : Foo { func foo() {...} }
>
> it is clear *why* foo is here..
>
> OK, now, let's assume you changed Foo protocol in the way, that
> SomeClass.swift *still* compiles :
>
> public protocol Foo { func bar() }
> extension Foo {
> func bar() {...}
> }
>
> Now, SomeClass.swift still compiles but it contains *wrong* intention that
> foo() method is an implementation of protocol requirement. And this can
> lead to bugs/unexpected behavior.
>
>
> I think what we do need a way to clearly shows intention that we defined
> some method *exactly* because the conformed protocol has it and to make
> compiler check this.
>
> My favorite solution is 'implements' keyword inside class/struct to
> highlight that I defined this 

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

[Adrian Zubarev via swift-evolution]

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 break anything. Furthermore, I’d love to see the addition 
where we could call the default implementation.

Here is some bikeshedding:

protocol A {}

extension A {
   func foo() { .. }
}

protocol B : A {}

extension B {
   // overriding default implementation from an other one!?  
   override func foo() {
// call default implementation of A
   default.foo()
}   
}

struct C : A {
   // overriding some default implementation  
   override func foo() {
  // call default implementation
   default.foo()
}
}

struct D : B {
  // overriding some default implementation  
   override func foo() {
  // call default implementation B
  // which will also call default implementation of A
   default.foo()
}
}


-- 
Adrian Zubarev
Sent with Airmail

Am 16. September 2016 um 20:45:05, Vladimir.S via swift-evolution 
(swift-evolution@swift.org) schrieb:

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 "Requiring proactive overrides for default protocol  
implementations." and in "Requiring special keyword to mark protocol  
implementation methods", probably in other threads also.

The first is that `override` is not used in structs, so IMO it will be  
alien here.
Second, if protocol has no default implementation for the method- would you  
require the `override(Protocol)` also?

Then, in case you will not require a keyword when no default implementation  
- you should think about retrospective adding of extension.

I.e. imagine, you have a source file, let's call it SomeClass.swift which  
you can't or don't want to change(this could be some complex source from  
3rd party, from github, or from other developer of your company). This file  
compiles without problems. It contains:

public protocol Foo { func foo() }
public class Some: Foo { func foo() {...} }

You added SomeClass.swift to your project and in your My.swift you added  
default implementation for Foo protocol:

extension Foo { func foo() {...} }

So, now, when you compile your project, there is default implementation for  
foo() and class Some should contains `override(Foo)`, but you can't change  
SomeClass.swift.


The only solution I see here, is if this `override(Foo)` will be optional,  
and just express developer's intention, if he/she wants this. I.e. it is  
not required, but if you specify it - compiler will check this intention.
But AFAIR unfortunately someone from core team mentioned that they don't  
want such optional solution.

And, at the end, I do think the real reason of your problem is not that  
protocol method has default implementation, but that  
`viewController(with:properties:)` definition in `FooController` does not  
say for compiler(and compiler does not check this) that this method was  
defined *exactly* to confirm to protocol. I.e. you can't clearly express  
your intention regarding why this method is here. Check this example:

Let's assume you defined protocol Foo in FooProto.swift file:

public protocol Foo { func foo() }

and have class `Some` conformed to Foo in SomeClass.swift:

public class Some : Foo { func foo() {...} }

it is clear *why* foo is here..

OK, now, let's assume you changed Foo protocol in the way, that  
SomeClass.swift *still* compiles :

public protocol Foo { func bar() }
extension Foo {
func bar() {...}
}

Now, SomeClass.swift still compiles but it contains *wrong* intention that  
foo() method is an implementation of protocol requirement. And this can  
lead to bugs/unexpected behavior.


I think what we do need a way to clearly shows intention that we defined  
some method *exactly* because the conformed protocol has it and to make  
compiler check this.

My favorite solution is 'implements' keyword inside class/struct to  
highlight that I defined this method as implementation for the protocol  
requirement. IMO solves a big percent of discussed issues with just one  
added keyword, that also will help with understanding the code when you  
read it.

Other solution that was mentioned by (as I remember) member of core team is  
treat class extension with protocol conformance as such intention, i.e.  
when you say
extension Some: Foo {..}
compiler will understand this as all methods inside such extension must  
'belongs' to the Foo protocol, i.e. if there is some method that does not  
exist in Foo - it will raise an error. But in this case we need to require  
that each protocol conformance will be declared as 

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

[Vladimir.S via swift-evolution]

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 "Requiring proactive overrides for default protocol 
implementations." and in "Requiring special keyword to mark protocol 
implementation methods", probably in other threads also.


The first is that `override` is not used in structs, so IMO it will be 
alien here.
Second, if protocol has no default implementation for the method- would you 
require the `override(Protocol)` also?


Then, in case you will not require a keyword when no default implementation 
- you should think about retrospective adding of extension.


I.e. imagine, you have a source file, let's call it SomeClass.swift which 
you can't or don't want to change(this could be some complex source from 
3rd party, from github, or from other developer of your company). This file 
compiles without problems. It contains:


public protocol Foo { func foo() }
public class Some: Foo { func foo() {...} }

You added SomeClass.swift to your project and in your My.swift you added 
default implementation for Foo protocol:


extension Foo { func foo() {...} }

So, now, when you compile your project, there is default implementation for 
foo() and class Some should contains `override(Foo)`, but you can't change 
SomeClass.swift.



The only solution I see here, is if this `override(Foo)` will be optional, 
and just express developer's intention, if he/she wants this. I.e. it is 
not required, but if you specify it - compiler will check this intention.
But AFAIR unfortunately someone from core team mentioned that they don't 
want such optional solution.


And, at the end, I do think the real reason of your problem is not that 
protocol method has default implementation, but that 
`viewController(with:properties:)` definition in `FooController` does not 
say for compiler(and compiler does not check this) that this method was 
defined *exactly* to confirm to protocol. I.e. you can't clearly express 
your intention regarding why this method is here. Check this example:


Let's assume you defined protocol Foo in FooProto.swift file:

public protocol Foo { func foo() }

and have class `Some` conformed to Foo in SomeClass.swift:

public class Some : Foo { func foo() {...} }

it is clear *why* foo is here..

OK, now, let's assume you changed Foo protocol in the way, that 
SomeClass.swift *still* compiles :


public protocol Foo { func bar() }
extension Foo {
  func bar() {...}
}

Now, SomeClass.swift still compiles but it contains *wrong* intention that 
foo() method is an implementation of protocol requirement. And this can 
lead to bugs/unexpected behavior.



I think what we do need a way to clearly shows intention that we defined 
some method *exactly* because the conformed protocol has it and to make 
compiler check this.


My favorite solution is 'implements' keyword inside class/struct to 
highlight that I defined this method as implementation for the protocol 
requirement. IMO solves a big percent of discussed issues with just one 
added keyword, that also will help with understanding the code when you 
read it.


Other solution that was mentioned by (as I remember) member of core team is 
treat class extension with protocol conformance as such intention, i.e. 
when you say

extension Some: Foo {..}
compiler will understand this as all methods inside such extension must 
'belongs' to the Foo protocol, i.e. if there is some method that does not 
exist in Foo - it will raise an error. But in this case we need to require 
that each protocol conformance will be declared as extension, not inline in 
class definition. Personally I don't believe in this solution.



On 16.09.2016 18:29, David Beck via swift-evolution wrote:

With the transition from Swift 2 -> 3 IБ─≥ve started running into one
particular issue VERY often (although itБ─≥s not necessarily specific to the
transition). If a protocol method is optional (either because it is an
@objc optional or because it has a default implementation) there is a risk
that the conformer will have a misspelled or slightly incorrectly typed
implementation of the method. For instance:

protocolRouteDestinationViewController: class{
staticfuncviewController(with url: URL, properties: [String:String]) ->
UIViewController?
}

extensionRouteDestinationViewControllerwhereSelf: UIViewController {
staticfuncviewController(with url: URL, properties: [String:String]) ->
UIViewController? {
returnSelf.init()
}
}

classFooController: UIViewController, RouteDestinationViewController{
staticfuncviewController(with url: URL, properties: [String:Any]) ->
UIViewController? {
returnFooController(properties: properties)
}
}

Notice the issue there? Properties is supposed to be [String:String], but
FooController uses [String:Any] (this is an exact issue I 

Re: [swift-evolution] Tuples as Named Types

[Robert Widmann via swift-evolution]

~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 know via JIRA or radar.

> Structs are usually used for slightly more complex objects compared to tuples 
> and usually, you need them longer in memory.

How is this a limitation?

> Tuples are just for quick manipulation. Since you are interested in just the 
> content inside, you should be able to manipulate it quickly. Concrete 
> examples would be destructing JSON or manipulating any list. That 
> manipulation itself shouldn't be something used with Switch statements or 
> require multiple if let statements.

A tuple is just as valid a data structure as any.  Though you may use them 
less, it does not mean they exist in a different semantic space than nominal 
types.  I don't see why you are averse to switch and case-let.  Switch allows 
you all the same power as your suggestion of using functions to "squash out" 
the Optionals from a tuple, and gives you diagnostics about completeness of 
case handling to boot.  

To your point, both of the operations you describe above are handled by 
destructuring into enums with associated values, not by matching on tuple 
patterns.  In fact, I think the only convincing case I've seen for the absolute 
need for tuple patterns is HLists , and nobody uses those anyway ;)

> 
> I'm actually not a fan of the C#'s implementation of tuples. Mainly because 
> they don't use optionals and the tuple implementation isn't very clean
> 
> var aTuple = Tuple.Create ("foo","bar",111)  
> 
> The main problem is that Swift's tuples functionalities are very limited to 
> be able to use them.

This is what I would like you to explain.  Please expound on the current 
limitations and what you wish to change.  So far, all I've seen is a suggestion 
for Monoidal Functors in stdlib.

> 
>> On Thu, Sep 15, 2016 at 10:25 PM, Robert Widmann  
>> wrote:
>> A few notes
>> 
>> ~Robert Widmann
>> 
>> 2016/09/16 0:54、Muhammad Tahir Vali via swift-evolution 
>>  のメッセージ:
>> 
>>> The purpose of this proposal is to implement Tuples as a named typed in 
>>> Swift. Tuples can be extremely useful for pattern matching, returning 
>>> multiple values from a function, and destructing content to the list. C# 
>>> has tuples as a named type as well I believe. Currently, Tuples in Swift 
>>> are anonymous types that have limited functionality but this proposal can 
>>> help solve that.
>> 
>> Languages like C#, Scala, et al. that decided that Tuple should be a nominal 
>> type have, in my opinion, made the wrong choice.  A tuple is an anonymous 
>> product; its content and not its name is what is important otherwise you'd 
>> just use a struct.
>> 
>>> 
>>> The underlying implementations of this proposal can allow the following :
>>> 
>>> 1) having parameters and return values of type : Tuple
>>> - enforces much more intuitive and clean code 
>>> - less code too read 
>> 
>> This is already valid in Swift.
>> 
>> func flip(_ t : (A, B)) -> (B, A) {
>>   return (t.1, t.0)
>> }
>> 
>>> 
>>> 2) implicit & explicit optionals with tuples !!! 
>>> - Can definitely take out many nested optional chains if tuples internally 
>>> checks for .Some or .None in each variable stored inside of an optional of 
>>> type Tuple.
>> 
>> This operation will not scale well without variadic generics.  Do you really 
>> want ~8 different functions in stdlib that examine the contents of tuples 
>> when it's much easier to just pattern match on the tuple in a `switch` or 
>> `case let` statement?
>> 
>>> 
>>> 3) making tuples variable declarations more popular for functional call
>>> - parameter names in function calls within tuple variables can be used as 
>>> getter
>> 
>> This is, again, already supported.
>> 
>> func project(_ t : (l : String, r : Int)) -> Int {
>>   return t.r
>> }
>> 
>> f(("Hello World, 42))
>> 
>>> 
>>> My proposal was very brief but I hope its one worth embracing. I didnt get 
>>> to talk about applications but those are pretty self-explanatory. This 
>>> definitely widens the vision for Swift and could be a "a-ha" thing for 
>>> Swift developers. :)
>> 
>> In short, I don't really see how this achieves the goal of making tuples 
>> more flexible.  Perhaps you have concrete examples of what is wrong and what 
>> this proposal intends to fix?
>> 
>>> 
>>> -- 
>>> Best Regards,
>>> 
>>> Muhammad T. Vali
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> 
> -- 
> Best Regards,
> 
> Muhammad T. Vali
___
swift-evolution mailing list
swift-evolution@swift.org

Re: [swift-evolution] Tuples as NominalTypes

[T.J. Usiyan via swift-evolution]

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 do hope
that, along with conditional conformance and the ability to add extensions
with self same types, we get the ability to define extensions on tuples.
These features would allow us more convenience when dealing with tuples and
might possibly ease the woes that you are presenting.

TJ

On Fri, Sep 16, 2016 at 4:05 PM, Muhammad Tahir Vali via swift-evolution <
swift-evolution@swift.org> wrote:

> 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, you should be able to manipulate it quickly. Concrete examples
> would be destructing JSON or manipulating any list. That manipulation
> itself shouldn't be something used with Switch statements or require
> multiple if let statements.
>
> I'm actually not a fan of the C#'s implementation of tuples. Mainly
> because they don't use optionals and the tuple implementation isn't very
> clean
>
> var aTuple = Tuple.Create ("foo","bar",111)
>
> The main problem is that Swift's tuples functionalities are very limited
> to be able to use them.
>
> --
> Best Regards,
>
> Muhammad T. Vali
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

[swift-evolution] Tuples as NominalTypes

[Muhammad Tahir Vali via swift-evolution]

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, you should be able to manipulate it quickly. Concrete examples
would be destructing JSON or manipulating any list. That manipulation
itself shouldn't be something used with Switch statements or require
multiple if let statements.

I'm actually not a fan of the C#'s implementation of tuples. Mainly because
they don't use optionals and the tuple implementation isn't very clean

var aTuple = Tuple.Create ("foo","bar",111)

The main problem is that Swift's tuples functionalities are very limited to
be able to use them.

-- 
Best Regards,

Muhammad T. Vali
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution