Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

In what way? On Sun, Apr 17, 2016 at 3:53 PM -0700, "Howard Lovatt" wrote: I think this should be part of completing generics. On Sunday, 17 April 2016, Yogev Sitton via swift-evolution wrote: I have a class that is conforming

Re: [swift-evolution] [Pitch] Unifying init parameters with properties

I think I like the idea... However IMHO this really feels like something that should be part of a macro system, not a "proper" language feature. - Dave Sweeris > On Apr 16, 2016, at 08:17, Jonathan Hull via swift-evolution > wrote: > > Since we know the types of

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

> Le 15 avr. 2016 à 17:59, Brent Royal-Gordon via swift-evolution > a écrit : > > A discussion in the "mapValues" thread reminded me of a longstanding issue I > have with Swift. > > `enumerate()` is an attractive nuisance. (That is, it looks like the thing > you

Re: [swift-evolution] API Guideline bugs and enhancements

The current API guideline suggests using xxx for mutating methods and either xxxed or xxxing for non-mutating, functional methods. I would suggest refine these rules to: 1. For mutating methods and get and set properties use an imperative verb phrase, e.g. `x.sort()`, use `xxx`. 2. For others

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

If something is to happen I cast my vote for #2. I actually—and intentionally—use what that would call `numbered()` rather frequently; it’s not hard to write but not having to write it is nicer. Since the “indexed” version is also useful it’d be nice to have both, and with unambiguous names.

Re: [swift-evolution] [Idea] Replace enumerate() with something more explicit

Yes I am proposing something like protocol Subscriptable that defines the subscript operation and indices and entries properties. On Sunday, 17 April 2016, Brent Royal-Gordon wrote: > > With the above definition I would suggest a name change to entries, > since a

Re: [swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

I think this should be part of completing generics. On Sunday, 17 April 2016, Yogev Sitton via swift-evolution < swift-evolution@swift.org> wrote: > I have a class that is conforming to a protocol with a method that > requires a specific return type. > In case I want to return a subclass of the

Re: [swift-evolution] [Idea] Passing an Array to Variadic Functions

Why not remove varargs altogether from Swift, it is easy enough to put [] round a list? On Monday, 18 April 2016, Keith Smiley via swift-evolution < swift-evolution@swift.org> wrote: > We've been dealing with this as well. We've chosen to go with your option > 1 for > most of our cases,

[swift-evolution] [Idea] Passing an Array to Variadic Functions

Hi! Currently, we can’t call a variadic function with an array of arguments. Reference: 1. http://stackoverflow.com/questions/24024376/passing-an-array-to-a-function-with-variable-number-of-args-in-swift

Re: [swift-evolution] [Draft] Expanded min/max algorithms

I *quite* like `extrema`/`indicesOfExtrema` over minmax. > On Apr 17, 2016, at 10:03 AM, Patrick Pijnappel > wrote: > > I like the idea. A few notes on naming: > – minIndex is somewhat confusing to me (it sounds like it's getting the > minimum index, i.e.

Re: [swift-evolution] [Draft] Expanded min/max algorithms

I like the idea. A few notes on naming: – minIndex is somewhat confusing to me (it sounds like it's getting the minimum index, i.e. indices.minElement()). How about indexOfMin() or indexOfMinElement()? – minmax() also doesn't read very well to me, plus it should technically be minMax() which is

[swift-evolution] [Pitch] Extend Any.Type to allow construction of bound generic types

I often find myself needing to construct an instance of a bound generic type at runtime, in much the same manner as I would a "standard" type. e.g. As for a standard type… let aType = Int.Type let anInt = aType.init(0) I also want to be able to use the same mechanism for a generic type…

Re: [swift-evolution] [Proposal] mapValues

I am definitely +1 for adding the initializer in any case. I would like to see it (based on Nate’s suggestion) have a “merge" parameter which takes a closure of (Key, Value, Value)throws->Value, which would be called to choose a value whenever a repeated key is encountered. That parameter

Re: [swift-evolution] [Draft] Expanded min/max algorithms

I like the idea. It worries me a bit if the general recipe for such situations is to add dedicated-purpose methods like `_customIndexOfMinComparableElement` (etc.) to standard-library protocols; it *will* work, but is only going to work for the methods that get such treatment. If it were

[swift-evolution] [PROPOSAL]Return subclass type to a protocol where a superclass is defined without the need for associatedtype

I have a class that is conforming to a protocol with a method that requires a specific return type. In case I want to return a subclass of the return type I am forced to use an associatedtype that feels like a hack. As an example: protocol MyShapeProtocol { func make() -> Shape? } class

Re: [swift-evolution] [Draft] Expanded min/max algorithms

On Sat, Apr 16, 2016 at 11:50 PM, Taras Zakharko via swift-evolution wrote: > Hi Nate, > > I think this is a very useful addition! I also had a related proposal few > days ago: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html > > I

Re: [swift-evolution] [Draft] Expanded min/max algorithms

Hi Nate, I think this is a very useful addition! I also had a related proposal few days ago: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014665.html I feel like min/max

[swift-evolution] [Draft] Expanded min/max algorithms

Hello all, Attached is a draft of a proposal to expand the min and max sequence APIs to better handle collections and to support future sorted sequences/collections. The proposal is in a gist here and inlined below—would