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

You may want to add the specific error to your proposal. *error: member operator '•|' must have at least one argument of type 'NonEmptyArray'* *public static func •|(lhs: Element, rhs: [Element]) -> NonEmptyArray* On Sat, Dec 10, 2016 at 11:49 PM Derrick Ho wrote:

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

I placed he code you wrote in the proposal in playgrounds and it works perfectly. (reproduced below). Overloading operators used to only happen globally and since swift 3 they allowed you to put then inside the class/struct public struct NonEmptyArray { fileprivate var elements: Array

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

I remember mentioning this in a meeting once. The old behavior (post 2.x-mid-operators-in-aggregates) did allow for this, the new one should too. ~Robert Widmann 2016/12/10 20:36、David Sweeris via swift-evolution のメッセージ: > >>> On Dec 10, 2016, at 5:29 PM, David

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

> On Dec 10, 2016, at 5:29 PM, David Sweeris via swift-evolution > wrote: > >> >> On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution >> > wrote: >> >> Hello, >> >> I have written a small

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

> On Dec 10, 2016, at 4:54 PM, Tommaso Piazza via swift-evolution > wrote: > > Hello, > > I have written a small proposal that would allow overloads of operators in > structs/classes non only based on the types of the operands but on the return > type as well. >

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

Hello, I have written a small proposal that would allow overloads of operators in structs/classes non only based on the types of the operands but on the return type as well. Please let me know you thoughts,/Tommaso

[swift-evolution] Partial class declaration

There is a lot of talk about stored properties in extensions. But do we really need them? Instead I think we can introduce something like partial classes from C#. It is an often case our classes go hell of a big and we have to move some methods to dedicated extensions to increase readability.

Re: [swift-evolution] Generic types―covariance/contravariance

As Braeden notes, the same compiler magic already works for most standard library container / monadic types. It could probably work in more cases. Let me clarify what I meant: This compiler magic is a very useful machinery that already exists and although the use cases are not wide enough to

Re: [swift-evolution] Generic types―covariance/contravariance

I did some experimenting, and I see that most variance situations are covered by the compiler. Generic collections and wrappers, like Optional or Array, are acceptable with .map and .flatMap, but currently benefit from compiler magic to cast those types. However, not all the standard library

Re: [swift-evolution] Generic types―covariance/contravariance

I wouldn’t keep it that narrow - monadic types like Optional also benefit from variance: func p(_ data:Any?) { if data != nil { data.map { print($0) } } } var a:String? = "foo" p(a) // -> “foo" -DW > On Dec 9, 2016, at 12:24 PM, Hooman Mehr via swift-evolution >

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

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. 2. Should have it’s own thread because the problem already exists today and is not yet formally solved.

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

I have to agree with Tino Heth, our aim is to add something basic at first. Although we’d better make sure that we will be able to add other wanted features in the future. How about this plan? 1. Generic protocols without associated types 2. Basic conflict resolution using “dot” syntax

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

> It seems like a lot of you are just trying to make different syntaxes for > generic protocols, which I’m pretty sure was never the concern about them? We > already have reasonable prior art here from the syntax of generic structs. yeah, this discussion has gotten much bigger than I expected:

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

Hi Anton and welcome back to the discussion. :) While trying to find the talk about overlapping protocol members from different protocols I spotted your proposal: https://github.com/Anton3/swift-evolution/blob/generic-protocols/proposals/-generic-protocols.md Just one hint, inside an