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 >>> wrote: >>> >>> >>> On D

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 於 2016年1月1日星期五 寫道： > > On Dec 31

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 are declared and implemented

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 { > > var a: Int > var

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 be

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 { > > var a: Int >

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 that to signify your >> sequence is multi-pass (i.e., to

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 de

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 GMT+0

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 implement it. > > -DW > >> On Dec

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 > func next() -

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] Closure Syntax

*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 are declared and implemented* Agreed, so lets flush out the rules a little more and see if we can fi

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 cov

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

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. -DW > On Dec 31, 2015, at 3:34 PM, Dmitri Gribenko wrote: > > On Thu, Dec 31, 2015 at 9:17 PM, David Waite via swi

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

+1 Sent from my iPad > On 1 Jan 2016, at 11:16 AM, Kevin Ballard via swift-evolution > wrote: > > 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

Re: [swift-evolution] Remove forEach?

You make a good point. `forEach` is simple for people new to the language and is relatively innocuous. It is also a 'stepping stone drug' to using `map`, `filter`, etc. :) Sent from my iPad > On 1 Jan 2016, at 11:55 AM, Tim Hawkins wrote: > > Just my 2 cents, > > forEach is a simple concept

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 ex

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] 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] Remove forEach?

Just my 2 cents, forEach is a simple concept to understand, it exists in most other languages that have a language level understanding of containers, retaining it has no downsides, but has the upside of making swift more approachable. 'map' on the otherhand may be much more powerful a construct,

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 30, 2015, at 01

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

> 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 >> a écrit : >>> On Wed, Dec 30, 2015, at 01:33 PM, Joe Groff wrote: Another possibility I've thought of is definin

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 have to do to deal with it? > > If a bin

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 > >> guarantee that val remains alive u

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

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. I kept the name "peek" for the method because, as mentioned in that email, there's plenty of precedent for it. -Kevin Ballard P.S.

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 bug is exercised as a s

[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 in

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] [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 ability in ObjC to extend framew

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] 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 buffer). Perhap

[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 &&

[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 _

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 ab

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 time comes, please post a video. > > ;-) > > -D

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 swift-evolution@swift.org ht

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 >> mailto:swift-evolution@swift.org>> wrote: >> >> If Swift would support non-type generic parameters, then I would like to >> have Boost.Unit l

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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> It's sometimes useful to get the first element of a sequence

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 { /// Returns the first element of

Re: [swift-evolution] Asserts should not cause undefined behaviour

> On Dec 31, 2015, at 12:27 PM, Chris Lattner via swift-evolution > wrote: > > On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution > wrote: >> The documented behaviour of assert and assertionFailure in "disable safety >> checks" builds (still documented as -Ounchecked) is that the c

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 “case B = 1+2”. Swift curre

[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 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 mailing list swift-evolu

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. That might let >> us leave `d

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] [Idea] Add AssociativeCollectionType to represent Dictionary-type relationships (was: Add an (Index, Element) sequence to CollectionType)

> On Dec 31, 2015, at 11:17 AM, David Waite > wrote: > > >> 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, b

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 discussion around the final/seale

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, Indexable is an implementatio

Re: [swift-evolution] Asserts should not cause undefined behaviour

On Dec 28, 2015, at 5:48 AM, Joseph Lord via swift-evolution wrote: > The documented behaviour of assert and assertionFailure in "disable safety > checks" builds (still documented as -Ounchecked) is that the compiler "may > assume that it would evaluate to true" or in the assertionFailure case

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 writ

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

> I don’t get the resistance to Dave’s solution? I think it works well and much > more applicable. I have two issues: 1. It's less discoverable. Someone merely *typing* `sort` into their editor will see `sortBy` right below it in their autocompletion list, and might discover it that way. 2. I

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

Sent from my iPad > On Dec 31, 2015, at 11:52 AM, Dave Abrahams wrote: > > >>> 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 wrote:

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

Sent from my iPad > On Dec 31, 2015, at 11:53 AM, Dave Abrahams wrote: > > >> On Dec 31, 2015, at 9:47 AM, Matthew Johnson wrote: >> >> In the second example here Forwarder does conform to P. The author of >> Forwarder has the flexibility to specify whether conformance is desired

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

Sent from my iPad > On Dec 31, 2015, at 12:02 PM, David Owens II wrote: > > >> 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 i

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 implementations from Dictionar

[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 other

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 talking about t

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. > > Moving back a ste

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] 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 trying to work them out, so it

Re: [swift-evolution] Proposal to remove semicolons

Oh and for the muscle memory argument: Switching from NSString * var to let var:String Was a bigger effort :D 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 wrote: >> >> In that case why did you accept to remov

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 wrote: >> >> In that case why did you accept to

Re: [swift-evolution] About the PermutationGenerator

I'm trying to work them out, so it's still muddled. Right now, I think SequenceType is better described as CollectionWalkType but that's kind of (1) a mouthful and (2) not entirely accurate. Moving back a step: SequenceType is defined as: "A type that can be iterated with a `for`...`in` loop."

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 proposal on GitHub under your sw

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

> On Dec 31, 2015, at 9:47 AM, Matthew Johnson wrote: > > In the second example here Forwarder does conform to P. The author of > Forwarder has the flexibility to specify whether conformance is desired > or not. There are ways to handle that, including factoring the API

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 >> > wrote: >>> >>> >>> >>> Sent from my iPad >>> >>> On

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 > > wrote: >> >>> >>> -Dave >>>

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); indices are not integers for al

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 31, 2015 at 00:33 Joe Groff v

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 swift-evolution >>> mailto:swift-evolution@swift.org>

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 address them? > > -- E >

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 propose no longer marking calls to

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. > Speaking of the Fibonacci-nu

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: I don’t want this thread to get d

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 >> starting with zero. >> > >

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 third parties. One com

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

I don’t get the resistance to Dave’s solution? I think it works well and much more applicable. Taking Susan’s original example, it’s not uncommon to want to sort or filter by multiple mechanisms. func byComparing(getComparisonKey: (T)->U) -> (T, T) -> Bool { return { getComparisonKey($0) <

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: (T)->U) -> (T, T) -> > Bool { > return { getComparisonKey($0) < getComparisonKey($1) }

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 > returning some sort of Offset or Slice

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 > creation dates.

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 >> Makes sense in general, but K

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 really

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] 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 any

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] 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 calculate the sequence one by

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] 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

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 one by one. But we are not

Re: [swift-evolution] About the PermutationGenerator

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 one by one. But we are not accessing the values of Fibonacci sequence. A socket can be

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 immut

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 > > wrote: > > It's sometimes u

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 only downside will di

Re: [swift-evolution] About the PermutationGenerator

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. But the PermutationGenerator break this rule, every time it changes it's state, it cannot get the generator with the start of sequenc

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. > One

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 09:53 AM, Joe G

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

  1   2   >