Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

It confuses people if provide a global function byComparing in stdlib which's doing nothing alone. Dave Abrahams 於 2015年12月31日星期四 寫道： > Why add all those algorithms when you can write this > > func byComparing(getComparisonKey: (T)->U) -> (T, T) -> > Bool

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

With the optimizer as it is today, if this were @_transparent could the extra function invocation(s) be optimized out when you use it in a non-escaping context such as sort()? Jacob On Thu, Dec 31, 2015 at 12:26 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > You

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

It's a choice with overriding methods or provide a global function which's missing @noescape version and has to write documentation to telling people what's it doing. However, sortBy method is common in other languages. Dave Abrahams 於 2015年12月31日星期四 寫道： > You don’t. Is

Re: [swift-evolution] Proposal: Add SequenceType.first

I submitted another proposal a few hours ago regarding @available(*, unavailable) that's designed to turn this into a compile-time error. Although I wonder if a stopgap would be to provide a `first` property on LazySequenceType that's marked as unavailable. I haven't checked to see how that

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

-Dave > On Dec 31, 2015, at 12:28 AM, Jacob Bandes-Storch wrote: > > With the optimizer as it is today, if this were @_transparent could the extra > function invocation(s) be optimized out when you use it in a non-escaping > context such as sort()? Sure. It doesn’t need

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

yes. Shouldn't have shorter names to replace the minElementBy, maxElementBy and sortInPlaceBy minBy and maxBy? Jacob Bandes-Storch 於 2015年12月31日星期四 寫道： > +1, although I wonder if the method names should be distinct (such as > minElementBy, sortBy, etc.) > > On Wed, Dec 30,

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

I don’t understand that argument. Obviously the function would be documented and there would be examples showing how to use it. Why would it confuse people? I think you’d need much stronger reasons to justify adding an unbounded set of overloads (is every algorithm that takes a comparison

Re: [swift-evolution] Proposal: Add SequenceType.first

> On Dec 30, 2015, at 3:57 PM, Kevin Ballard via swift-evolution > wrote: > > It's sometimes useful to get the first element of a sequence. To that end I'd > like to propose > > extension SequenceType { > /// Returns the first element of `self`, or `nil` if

Re: [swift-evolution] About the PermutationGenerator

On Thu, Dec 31, 2015 at 2:01 PM, Susan Cheng via swift-evolution < swift-evolution@swift.org> wrote: > As I know SequenceType should have behaved as immutable structure and it > provides method to get a mutable GeneratorType which generates value from > start of sequence. Sequences are not

Re: [swift-evolution] About the PermutationGenerator

> Those are collections. Collections can be iterated over multiple times. Speaking of the Fibonacci-numbers: Sure we can write an algorithm that iterates over them several times — it just won't ever finish the first iteration ;-) (only nitpicking — I just couldn't resist) Happy new year!

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

> On Dec 31, 2015, at 5:44 AM, Tino Heth <2...@gmx.de> wrote: > > This is some sort of a cross-post from another thread ["automatic protocol > forwarding"] — for anyone who wants to follow, I recommend to read > https://kotlinlang.org/docs/reference/classes.html >

Re: [swift-evolution] Proposal: Add SequenceType.first

Generator should always generates value from start of sequence. I don't see any problems with this implementation. Dave Abrahams via swift-evolution 於 2015年12月31日星期四 寫道： > On Dec 30, 2015, at 3:57 PM, Kevin Ballard via swift-evolution < > swift-evolution@swift.org >

Re: [swift-evolution] About the PermutationGenerator

On Thu, Dec 31, 2015 at 3:04 PM, Susan Cheng wrote: > yes for sequences are not immutable. I get confused. > > no for sequences should be definition of lists of values. Just like > Fibonacci sequence, we can calculate the values form the start of the > Fibonacci sequence

Re: [swift-evolution] About the PermutationGenerator

I don't think so. As we don't say "Fibonacci collection", we know Fibonacci numbers are in order. But we can't tell the number immediately if I asked a specific index of Fibonacci sequence. The only way is calculate the sequence one by one from start. So we need the collection, and collection do

Re: [swift-evolution] About the PermutationGenerator

sequence can have more methods with it, we can find first five values of a sequence. but we don't do this with a generator struct Fibonacci: SequenceType { var first, second: Int func generate() -> AnyGenerator { var a = first var b = second return

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

Honest question, where's the guarantee that the optimizer isn't allowed to optimize defer {val} away? On Thu, Dec 31, 2015 at 00:33 Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > On Dec 30, 2015, at 1:27 PM, Kevin Ballard wrote: > > On Wed, Dec 30, 2015, at

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

> func byComparing(getComparisonKey: (T)->U) -> (T, T) -> > Bool { > return { getComparisonKey($0) < getComparisonKey($1) } > } I've written something similar to bring file URLs into the order of their creation dates. It is a small extension for collection types, and its

Re: [swift-evolution] About the PermutationGenerator

On Thu, Dec 31, 2015 at 3:36 PM, Susan Cheng wrote: > I don't think so. > > As we don't say "Fibonacci collection", we know Fibonacci numbers are in > order. But we can't tell the number immediately if I asked a specific index > of Fibonacci sequence. The only way is

Re: [swift-evolution] Remove forEach?

I like having separate forEach. As already said, forEach produces different visual grouping of logic compared to for operator. It's especially useful if you just pass a named function to it. forEach is also not the same as map: let block: Int -> Void = ... [1,2,3].map(block) Here the result has

Re: [swift-evolution] [Proposal Draft] Flexible memberwise initialization

This is some sort of a cross-post from another thread ["automatic protocol forwarding"] — for anyone who wants to follow, I recommend to read https://kotlinlang.org/docs/reference/classes.html The idea of "function-like class declaration" has

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> I don’t want this thread to get distracted with memberwise initialization Makes sense in general, but Kotlin solves those problems as a whole, and the major benefit of their approach is that everything fits together really fine. But I'll skip everything that is not related to forwarding. >

Re: [swift-evolution] About the PermutationGenerator

On Thu, Dec 31, 2015 at 3:51 PM, Tino Heth <2...@gmx.de> wrote: >> Those are collections. Collections can be iterated over multiple times. > Speaking of the Fibonacci-numbers: > Sure we can write an algorithm that iterates over them several times — it > just won't ever finish the first iteration

Re: [swift-evolution] [Idea] Add AssociativeCollectionType to represent Dictionary-type relationships (was: Add an (Index, Element) sequence to CollectionType)

> On Dec 29, 2015, at 2:37 PM, David Waite via swift-evolution > wrote: > > >> Anyway, it would not be correct to ".enumerate()" returns (Index, Element) >> instead of (n, Element)? >> >> I believe that the current behavior was thought when Slices had indices >>

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> On Dec 27, 2015, at 10:25 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> So “try” instead of “do”. If there is no catch, then just use braces without >> a keyword for a block. >> >> And use do-while instead of repeat-while. +1 > > Do you also

Re: [swift-evolution] Pitch: "while" clause on for-loops

> On Dec 31, 2015, at 12:42 AM, Jacob Bandes-Storch via swift-evolution > wrote: > > Currently, for-loops admit a "where" clause: > > for x in seq where cond { > ... > } > > behaves like > > for x in seq { > if !cond { continue } >

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 30, 2015, at 1:22 PM, Kevin Ballard wrote: > > A uniquely-owned class that guarantees stack allocation is pretty much the > same thing as a move-only value type, isn't it? The only real difference I > can think of is classes allow for subclassing. At this point, we’re

Re: [swift-evolution] rename dropFirst() and dropLast()

> On Dec 29, 2015, at 10:23 PM, David Waite > wrote: > > I do rather like that, although the thread stalled a week ago which is > equivalent to 1 swift-evolution year :-) > > Is the current thinking that “$ + 3” and its ilk be a literal or computation >

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 31, 2015, at 11:18 AM, Dave Abrahams wrote: > >> >> On Dec 31, 2015, at 9:01 AM, Matthew Johnson > > wrote: >> >> >> >> Sent from my iPad >> >> On Dec 31, 2015, at 10:09 AM, Dave Abrahams

Re: [swift-evolution] Proposal to remove semicolons

Thank you guys for the emails. I guess i will have to deal with the fact that we have semicolons for the end of line :) Joao Sent from my iPhone > On 15 Dec 2015, at 23:28, Chris Lattner wrote: > > >> On Dec 15, 2015, at 12:11 AM, João Nunes

Re: [swift-evolution] About the PermutationGenerator

Just to add to that, it’s always seemed strange to me that to signify your sequence is multi-pass (i.e., to make it conform to CollectionType) you have to have it conform to Indexable. > On 31 Dec 2015, at 17:52, Erica Sadun via swift-evolution > wrote: > > I'm

Re: [swift-evolution] [Idea] Add AssociativeCollectionType to represent Dictionary-type relationships (was: Add an (Index, Element) sequence to CollectionType)

> On Dec 31, 2015, at 9:53 AM, Dave Abrahams wrote: > > What is the use-case for this protocol? I actually suspect you have a better grasp of the pros and cons based on your prior experience, but here goes: An AssociativeCollectionType would allow for alternate

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

> On Dec 31, 2015, at 4:14 AM, Tino Heth <2...@gmx.de> wrote: > > >> func byComparing(getComparisonKey: (T)->U) -> (T, T) -> >> Bool { >> return { getComparisonKey($0) < getComparisonKey($1) } >> } > I've written something similar to bring file URLs into the order of their

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

What's problem of overloading? We only have four methods to do so. Dave Abrahams 於 2016年1月1日星期五 寫道： > > On Dec 31, 2015, at 4:14 AM, Tino Heth <2...@gmx.de > > wrote: > > > func byComparing(getComparisonKey:

Re: [swift-evolution] About the PermutationGenerator

It does seem that in Swift the concepts of collection, sequence, permutation, stream, etc are a bit muddled. -- E > On Dec 31, 2015, at 6:51 AM, Tino Heth via swift-evolution > wrote: > >> Those are collections. Collections can be iterated over multiple times. >

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 31, 2015, at 9:01 AM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Dec 31, 2015, at 10:09 AM, Dave Abrahams > wrote: > >> >> -Dave >> >>> On Dec 31, 2015, at 7:33 AM, Matthew Johnson via

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 31, 2015, at 9:47 AM, Matthew Johnson via swift-evolution > wrote: > > No. This is addressed in the proposal and the lazy collections motivating > example I replied with last night. I don’t think it’s a good idea to require > this. Can you put your

Re: [swift-evolution] [Idea] Add an (Index, Element) sequence to CollectionType

> On Dec 29, 2015, at 8:06 AM, Wallacy via swift-evolution > wrote: > > I believe that the current behavior was thought when Slices had indices > starting with zero. The current behavior was intentional (and intentionally left as-is when array slices changed);

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 31, 2015, at 9:47 AM, Matthew Johnson wrote: > >> >> On Dec 31, 2015, at 11:18 AM, Dave Abrahams > > wrote: >> >>> >>> On Dec 31, 2015, at 9:01 AM, Matthew Johnson >>

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 31, 2015, at 5:04 AM, Tino Heth <2...@gmx.de> wrote: > > >> I don’t want this thread to get distracted with memberwise initialization > Makes sense in general, but Kotlin solves those problems as a whole, and the > major benefit of their approach is that everything fits together

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

-Dave > On Dec 31, 2015, at 7:33 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On Dec 31, 2015, at 5:04 AM, Tino Heth <2...@gmx.de > >> wrote: >> >> >>> I don’t want this thread to get distracted with memberwise initialization >>

Re: [swift-evolution] sortBy, minElementBy and maxElementBy methods

> On Dec 31, 2015, at 8:44 AM, Susan Cheng wrote: > > What's problem of overloading? We only have four methods to do so. The set of potential algorithms using comparison predicates is not closed, and they will be implemented not only by the standard library but also by

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

Sent from my iPad > On Dec 31, 2015, at 10:09 AM, Dave Abrahams wrote: > > > -Dave > >>> On Dec 31, 2015, at 7:33 AM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> On Dec 31, 2015, at 5:04 AM, Tino Heth <2...@gmx.de> wrote:

Re: [swift-evolution] About the PermutationGenerator

> On Dec 31, 2015, at 9:05 AM, Erica Sadun via swift-evolution > wrote: > > It does seem that in Swift the concepts of collection, sequence, permutation, > stream, etc are a bit muddled. This is a pretty vague critique. Do you have specifics, and suggestions that

Re: [swift-evolution] Epic: Typesafe calculations

> On Dec 25, 2015, at 4:43 PM, Nickolas Pohilets via swift-evolution > wrote: > > If Swift would support non-type generic parameters, then I would like to have > Boost.Unit library > (http://www.boost.org/doc/libs/1_60_0/doc/html/boost_units.html >

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

> On Dec 31, 2015, at 2:48 AM, ilya wrote: > > Honest question, where's the guarantee that the optimizer isn't allowed to > optimize defer {val} away? There isn't one, today. It would be a language change if we wanted to make that guarantee. -Joe > On Thu, Dec

Re: [swift-evolution] About the PermutationGenerator

> On Dec 31, 2015, at 9:52 AM, Erica Sadun wrote: > > I'm trying to work them out, so it's still muddled. > > Right now, I think SequenceType is better described as CollectionWalkType Why do you say so? > but that's kind of (1) a mouthful and (2) not entirely accurate.

[swift-evolution] [Pitch] Version-pinned patching of public declarations

A lot of the discussion around the final/sealed-by-default issue focused on the ability in ObjC to extend frameworks or fix bugs in unforeseen ways. Framework developers aren't perfect, and being able to patch a broken framework method can be the difference between shipping and not. On the

Re: [swift-evolution] About the PermutationGenerator

> On Dec 31, 2015, at 10:52 AM, Donnacha Oisín Kidney > wrote: > > Just to add to that, it’s always seemed strange to me that to signify your > sequence is multi-pass (i.e., to make it conform to CollectionType) you have > to have it conform to Indexable. FWIW,

Re: [swift-evolution] Proposal: Add SequenceType.first

On Thu, Dec 31, 2015, at 12:36 AM, Dave Abrahams wrote: >> On Dec 30, 2015, at 3:57 PM, Kevin Ballard via swift-evolution >> wrote: >> >> It's sometimes useful to get the first element of a sequence. To that >> end I'd like to propose >> >> extensionSequenceType { ///

[swift-evolution] Philosophy question: Foundation and Standard Library

Under what criteria should we propose moving items into the standard library and out from the standard library into Swift Foundation? Or will these things eventually merge and become one grand unified module sometime in the distant future? Thanks, -- E

[swift-evolution] Proposal: Variable invariants

Examples: var x:(Int where 1…10 ~= x) = 5 var y:(Double where trunc(y*2) == y*2) = 3.5 x = 11 // run-time error y = 3.6 // run-time error typealias T = Double(y) where trunc(y*2) == y*2 var y2:T = 4.5 // type for 10x10 grid of integers typealias Grid = [[Int]](g) where g.indices == 0..<10 &&

Re: [swift-evolution] Remove forEach?

I suspect that if there were an 'advanced' `map` it would largely eliminate `forEach` since a main use of `forEach` is because of limitation in map like multiple returns, combined map and filtering, etc. The comment that you have to ignore a warning is however a valid point, perhaps like other

Re: [swift-evolution] Epic: Typesafe calculations

> On Dec 31, 2015, at 09:25, Dave Abrahams via swift-evolution > wrote: > >> >> On Dec 25, 2015, at 4:43 PM, Nickolas Pohilets via swift-evolution >> > wrote: >> >> If Swift would support non-type

Re: [swift-evolution] Proposal: Add SequenceType.first

On Thu, Dec 31, 2015, at 02:03 PM, Dave Abrahams wrote: > >> On Dec 31, 2015, at 1:58 PM, Kevin Ballard wrote: >> >> Good idea, though I'd probably call it PeekSequence because it would >> only buffer a single element (and BufferedSequence sounds like it's >> got an arbitrary-sized

Re: [swift-evolution] Proposal: Add SequenceType.first

Related to this I've been toying around with a tweak to GeneratorType - it could clear up some of the issues with .first consuming part of the sequence: public protocol NewGeneratorType { typealias Element func next() -> (value: Element, state: Self)? } extension NewGeneratorType {

Re: [swift-evolution] [Proposal] Protocols on Steroids

Yeah I can see that "it is too big" is a valid criticism, I will try and split it up. The reason that I didn't split it before was that the proposals work well together. "Sum greater than the parts". Anyway now that there is a place marker for the whole it can be split and reference made to the

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

Le 30 déc. 2015 à 16:40, Kevin Ballard via swift-evolution a écrit : > On Wed, Dec 30, 2015, at 01:33 PM, Joe Groff wrote: >> Another possibility I've thought of is defining `defer { val }` to guarantee >> that val remains alive until the defer fires on scope exit.

Re: [swift-evolution] Epic: Typesafe calculations

> On Dec 31, 2015, at 14:23, Dave Abrahams wrote: > > >> On Dec 31, 2015, at 2:18 PM, Matt Whiteside > > wrote: >> >> I will do cartwheels when we can write stuff like Vector<3> or Tensor<4,4,4> > > > When the

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

On Thu, Dec 31, 2015, at 01:40 PM, Michel Fortin wrote: > Le 30 déc. 2015 à 16:40, Kevin Ballard via swift-evolution > a écrit : > > On Wed, Dec 30, 2015, at 01:33 PM, Joe Groff wrote: > >> Another possibility I've thought of is defining `defer { val }` to > >>

Re: [swift-evolution] [Pitch] Version-pinned patching of public declarations

> On Dec 31, 2015, at 4:16 PM, Joe Groff wrote: > > >> On Dec 31, 2015, at 1:20 PM, Dave Abrahams wrote: >> >> Hi Joe, >> >> Can you compare the developer experience with/without this feature, e.g. >> paint some scenarios and describe what one would

Re: [swift-evolution] Proposal: Add SequenceType.first

On Thu, Dec 31, 2015, at 12:40 AM, Dave Abrahams wrote: >> Another motivation for adding this that I forgot to mention is that >> today the code `someCol.lazy.filter(pred).first` actually isn't lazy >> at all, it filters the entire collection and builds a new array >> (because SequenceType doesn't

Re: [swift-evolution] Proposal: Add SequenceType.first

> On Dec 31, 2015, at 1:58 PM, Kevin Ballard wrote: > > On Thu, Dec 31, 2015, at 12:36 AM, Dave Abrahams wrote: >>> On Dec 30, 2015, at 3:57 PM, Kevin Ballard via swift-evolution >>> > wrote: >>> >>> It's sometimes

Re: [swift-evolution] [Pitch] Version-pinned patching of public declarations

I definitely feel this is a great direction for a compromise. This outlines the issues involved well. Rod > On 1 Jan 2016, at 6:13 AM, Joe Groff via swift-evolution > wrote: > > A lot of the discussion around the final/sealed-by-default issue focused on > the

Re: [swift-evolution] [Proposal] Scoped resources (like C# using statement)

On Thu, Dec 31, 2015, at 04:46 PM, Joe Groff wrote: > >> On Dec 31, 2015, at 4:26 PM, Kevin Ballard wrote: >> >> On Thu, Dec 31, 2015, at 01:40 PM, Michel Fortin wrote: >>> Le 30 déc. 2015 à 16:40, Kevin Ballard via swift-evolution >> evolut...@swift.org> a écrit : On Wed, Dec

Re: [swift-evolution] [Proposal] Protocols on Steroids

There is a significant downside to variance in Java and Scala, you have to annotate your code all over the place. This annotation completely clutters your code, much like Swift is a lot 'cleaner' than Java, all the annotations detract. You see the same effect in code that uses Java arrays which

Re: [swift-evolution] use standard syntax instead of "do" and "repeat"

> There are large classes of programs where you can know you don’t care exactly > where a failure happens, e.g. (most init functions, all pure functions, any > function that doesn’t break invariants). In these cases marking every > statement or expression that can throw is just noise. Try

Re: [swift-evolution] [Pitch] Version-pinned patching of public declarations

Hi Joe, Can you compare the developer experience with/without this feature, e.g. paint some scenarios and describe what one would have to do to deal with it? Thanks, Dave > On Dec 31, 2015, at 11:13 AM, Joe Groff via swift-evolution > wrote: > > A lot of the

Re: [swift-evolution] [Proposal Draft] automatic protocol forwarding

> On Dec 31, 2015, at 11:42 AM, Matthew Johnson wrote: > > I will continue to work on motivating examples, several of which will take > advantage of this relaxed requirement. Looking forward to it! -Dave ___ swift-evolution

[swift-evolution] Proposal: Support constant expressions in enum case raw values.

Example: enum A : [Int] { case B = [1,2,3] } Currently, the following error occurs: "raw value for enum case must be a literal" ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Support constant expressions in enum case raw values.

> On Dec 31, 2015, at 1:46 PM, Amir Michail via swift-evolution > wrote: > > Example: > > enum A : [Int] { >case B = [1,2,3] > } > > > Currently, the following error occurs: "raw value for enum case must be a > literal” A more typically requested example is

Re: [swift-evolution] Epic: Typesafe calculations

> On Dec 31, 2015, at 2:18 PM, Matt Whiteside wrote: > > I will do cartwheels when we can write stuff like Vector<3> or Tensor<4,4,4> When the time comes, please post a video. ;-) -Dave ___ swift-evolution mailing list

Re: [swift-evolution] [Idea] Add AssociativeCollectionType to represent Dictionary-type relationships (was: Add an (Index, Element) sequence to CollectionType)

On Thu, Dec 31, 2015 at 9:17 PM, David Waite via swift-evolution < swift-evolution@swift.org> wrote: > > - Array has additional mutating methods which are not described by > CollectionType or any other protocol. The ease of getting a new copy of an > array and mutating it means code needing the

Re: [swift-evolution] [Pitch] Version-pinned patching of public declarations

> On Dec 31, 2015, at 1:20 PM, Dave Abrahams wrote: > > Hi Joe, > > Can you compare the developer experience with/without this feature, e.g. > paint some scenarios and describe what one would have to do to deal with it? If a binary framework ships with a bug, and that

[swift-evolution] Proposal: Add types BufferedSequence, BufferedGenerator

BufferedSequence is a sequence adaptor that wraps any underlying sequence and provides a stable `first` property. BufferedGenerator is a generator adaptor that wraps any underlying generator and provides arbitrary lookahead with a `peek(n: Int)` method. The method name "peek()" has precedent

Re: [swift-evolution] [Proposal] Protocols on Steroids

I would much rather have proper support for covariance/contravariance than pretty but unsound code. It's been stated in other threads that making things pretty is not, in and of itself, a Swift project goal. I like most of the other proposals, although I think most of them are covered by the

Re: [swift-evolution] [Proposal] Protocols on Steroids

Skimming it again, here's some brief commentary on your other suggestions: On Wed, Dec 30, 2015, at 02:50 PM, Howard Lovatt via swift-evolution wrote: > 1. Generic protocol with type parameters inside `<>`, like classes > and structs I believe this has already been proposed. > 1. Allow

Re: [swift-evolution] About the PermutationGenerator

> On Dec 31, 2015, at 7:46 PM, Susan Cheng wrote: > > > How GeneratorType confirm to Equatable?? I don’t understand the question. In the code I posted there’s a working example of how a GeneratorType model can conform to Equatable.. > > struct Fib : SequenceType {

Re: [swift-evolution] About the PermutationGenerator

> On Dec 31, 2015, at 1:02 PM, Dave Abrahams via swift-evolution > wrote: > >> >> On Dec 31, 2015, at 10:52 AM, Donnacha Oisín Kidney > > wrote: >> >> Just to add to that, it’s always seemed strange to me

Re: [swift-evolution] About the PermutationGenerator

if you try my modification, it will crash. struct Fib : SequenceType { var a: Int var b: Int var limit: Int func generate() -> FibGenerator { return Generator(a: a, b: b, limit: limit) } } let c = Multipass(Fib(a: 1, b: -1, limit: 10)) A SequenceType

Re: [swift-evolution] About the PermutationGenerator

I didn't explain correctly. let's take this: let c = Multipass(Fib(a: 1, b: -1, limit: 10)) this sequences should have results with [1, -1, 0, -1, -1, ...] So is c.startIndex.successor() equal to c.startIndex.successor().successor().successor()?? Dave Abrahams 於

Re: [swift-evolution] Epic: Typesafe calculations

Same here. I can fake a bit of it now by creating the relevant types ("struct _1 {...}", etc), but it's *very* fragile. > On Dec 31, 2015, at 14:18, Matt Whiteside via swift-evolution > wrote: > > >>> On Dec 31, 2015, at 09:25, Dave Abrahams via swift-evolution

Re: [swift-evolution] Proposal: Add SequenceType.first

> On Dec 31, 2015, at 3:36 PM, Andrew Bennett wrote: > > Related to this I've been toying around with a tweak to GeneratorType - it > could clear up some of the issues with .first consuming part of the sequence: > > public protocol NewGeneratorType { > typealias Element

Re: [swift-evolution] About the PermutationGenerator

How GeneratorType confirm to Equatable?? struct Fib : SequenceType { var a: Int var b: Int var limit: Int func generate() -> FibGenerator { return Generator(a: a, b: b, limit: limit) } } let c = Multipass(Fib(a: 1, b: -1, limit: 10)) -Susan 2016-01-01 11:17

Re: [swift-evolution] [Idea] Add AssociativeCollectionType to represent Dictionary-type relationships (was: Add an (Index, Element) sequence to CollectionType)

> On Dec 31, 2015, at 6:09 PM, David Waite wrote: > > Interesting! I never saw any collections outside of the String views > implement that, probably because the swift standard library docs don’t > publish underscore-prefixed protocols. The Array types all

Re: [swift-evolution] Closure Syntax

On Dec 31, 2015, at 6:16 PM, Ethan Diamond via swift-evolution wrote: > There are three pieces at play here IMHO: > 1. How functions (global and on types) are declared and implemented > 2. How function specifications are indicated as types > 3. How anonymous functions

Re: [swift-evolution] About the PermutationGenerator

> On Dec 31, 2015, at 8:22 PM, 鄭齊峯 via swift-evolution > wrote: > > if you try my modification, it will crash. Only because your Sequence genereates an arithmetic underflow. I don’t understand what point you’re trying to make > > struct Fib : SequenceType { >

Re: [swift-evolution] Proposal: Add SequenceType.first

> On Dec 31, 2015, at 4:19 PM, Kevin Ballard wrote: > > I've submitted a proposal to the ML for BufferedSequence / BufferedGenerator > as > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151228/005010.html > >

Re: [swift-evolution] [Idea] Add AssociativeCollectionType to represent Dictionary-type relationships (was: Add an (Index, Element) sequence to CollectionType)

First, let me say that basic premise was intended to be “I would like the ability to have a protocol for dictionary-type objects rather than have it be a single implementation for several reasons, but I expect that there would also be several hurdles to doing so”. It is more of an idea than a