Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

Hello Derrick, I did not think of this as a bug but rather as an intentional limitation that to me seems a little odd. Yes, overloads 2,3 have at least ONE operand of type NonEmptyArray so when declared as static function on NonEmptyArray they work fine. However Overload 1 just mentions

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

Thanks for the suggestion, I have updated the proposal with the error and with the notes on `fileprivate` -> `private` /Tommaso On Sunday, December 11, 2016 5:55 AM, Derrick Ho wrote: You may want to add the specific error to your proposal.   error: member

Re: [swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)

Hi everyone, I read every post in the Higher-Kinded Types ( https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html ) thread from about a year ago, and I was wondering what's the

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

imho the current behaviour is fine. I'll leave aside infix-operators, because with pre/postfix, the situation is simpler: It seems slightly confusing to me to declare such an operator somewhere else but at the type it works on. Afair the ability to declare an infix operator in a type

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

It bugs me as well that we can not test private components using XCTest. Objective-c never had this problem since privacy doesn't exist. I would like to see a version of XCTest that allows us to test every component. On Mon, Dec 12, 2016 at 12:02 AM Benjamin Spratling via swift-evolution <

Re: [swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)

Hi Chris, thanks a lot for the answer, that's exactly what I wanted to read and it gives me hope for the language's future :) - Elviro > Il giorno 12 dic 2016, alle ore 06:46, Chris Lattner ha > scritto: > > On Dec 11, 2016, at 5:48 AM, Elviro Rocca via swift-evolution >

Re: [swift-evolution] [Proposal] Higher Kinded Types (Monads, Functors, etc.)

On Dec 11, 2016, at 5:48 AM, Elviro Rocca via swift-evolution wrote: > Hi everyone, I read every post in the Higher-Kinded Types ( > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html > >

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

-Ben Sent from my iPhone. > On Dec 11, 2016, at 11:43 PM, Brian Gesiak wrote: > Maybe your goal is to ensure that other programmers don't accidentally change > the accessibility levels. Again, I think because they're straightforward, I > don't think there's much danger

[swift-evolution] adding automated-testing of uncompilable features in XCTest

Howdy, I’d like to see how much interest there is for adding these to the XCTest module. If I have missed some pro or con, or missed a technical point, your feedback is welcome before I go to the lengths to draw up a formal proposal. There are several features of Swift which cannot

Re: [swift-evolution] adding automated-testing of uncompilable features in XCTest

Hi Benjamin, I think your proposal is interesting, and you're certainly right: XCTest has no way to test accessibility levels, or the other attributes you mention. However, I wonder, what do you hope to achieve by adding an automated test for accessibility levels? Maybe your goal is to verify

Re: [swift-evolution] [Discussion] Generic protocols

2016-12-10 14:57 GMT+03:00 Adrian Zubarev : I’m fine with adding features step by step. ;) > > There is no need for an explicit type alias in your > > extension MyStruct : Constructible { … } > > Because Value is already constrained by String. > That was my

Re: [swift-evolution] Proposal: Allows operator overloads in struct or classes based on return type

I cannot reply directly to this message  https://www.mail-archive.com/swift-evolution@swift.org/msg19099.html so I will reply here instead. I am suggesting that both behaviours should be allowed to co-exists (which is already the case, just there is this one exception.) No matter the