Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Hi all, I have few problems with this proposal. How we guarantee the arguments type are what we need? If we passing the type to the dynamicCall that are not acceptable, what will happened? Should we always write the dynamicCall as a throwing function to check the precondition? Instead of

Re: [swift-evolution] [Proposal] Random Unification

First of all, I like this proposal. For a empty RandomAccessCollection, is it cause a fatal error with calling the random methods? > Alejandro Alonso via swift-evolution 於 2017年9月26日 > 下午12:57 寫道： > > Hello evolution, > > I am very thankful for all the feedback,

Re: [swift-evolution] [Proposal] Random Unification

Hello, I have an implementation for reference https://github.com/SusanDoggie/Doggie/blob/master/Sources/Doggie/Foundation/Random.swift It's easy to remind that what's the range of random floating point number Double.random(includeOne: true) Double.random(includeOne: false) 2017-09-09 0:52

[swift-evolution] [Concurrency] async/await + actors

> Hi all, > > As Ted mentioned in his email, it is great to finally kick off discussions for what concurrency should look like in Swift. This will surely be an epic multi-year journey, but it is more important to find the right design than to get there fast. > > I’ve been advocating for a

Re: [swift-evolution] Swift 5: start your engines

is it accept proposal for coroutine? Just like the one i had proposed before: https://github.com/apple/swift-evolution/pull/73 2017-08-09 0:23 GMT+08:00 Ted Kremenek via swift-evolution < swift-evolution@swift.org>: > Hi everyone, > > The proposal phase for Swift 4 is now officially over, and

Re: [swift-evolution] [Proposal] Introduces endianness specific type

to a file, because > their layout can change. When ABI stability for fragile structs lands, you > will be able to count on it, but until then something like this is probably > a bad idea. > > -Chris > > On Jul 7, 2017, at 6:16 PM, Susan Cheng via swift-evolution < > swift

Re: [swift-evolution] [Proposal] Introduces endianness specific type

> Hi Susan, > > Was there any motivation for this proposal that I missed? If not then, can > you please provide it in a few sentences? Otherwise it’s not clear to me what > problem it is supposed to fix. > > Thanks, > Max > > >> On Jul 6, 2017, at 8:21 PM, Susa

[swift-evolution] [Proposal] Introduces endianness specific type

IMO, it has unclear representation when FixedWidthInteger working with endianness specific type. so I want to introduce the endianness specific wrapper: public struct BEInteger : FixedWidthInteger { public var bigEndian: BEInteger { get } public var littleEndian: LEInteger { get

Re: [swift-evolution] History and future of Swift's parentheses

It may make things more terrible. The solution introduces two separated type system and one is Swift 3 mode for asterisk syntax. > Robert Bennett via swift-evolution 於 2017年6月10日 > 上午6:02 寫道： > > I see. My ideal solution to this would be an explicit tuple packing

Re: [swift-evolution] Pitch: Support for map and flatMap with smart key paths

this work, prefix operator * prefix func *(keyPath: KeyPath) -> (Root) -> Value { return { $0[keyPath: keyPath] } } ["Hello, World"].map(*\String.count)// [12] 2017-06-08 12:19 GMT+08:00 Paul Cantrell via swift-evolution < swift-evolution@swift.org>: >

Re: [swift-evolution] Proposal: Always flatten the single element tuple

that makes sense to me ;P 2017-06-08 12:07 GMT+08:00 Gwendal Roué <gwendal.r...@gmail.com>: > Le 8 juin 2017 à 05:15, Susan Cheng via swift-evolution < > swift-evolution@swift.org> a écrit : > > Just a thought > > if parentheses is important, why the tuples are

Re: [swift-evolution] Proposal: Always flatten the single element tuple

) } 2017-06-08 11:36 GMT+08:00 Xiaodi Wu <xiaodi...@gmail.com>: > On Wed, Jun 7, 2017 at 10:15 PM, Susan Cheng via swift-evolution < > swift-evolution@swift.org> wrote: > >> Just a thought >> >> if parentheses is important, why the tuples are not? >>

Re: [swift-evolution] Proposal: Always flatten the single element tuple

Just a thought if parentheses is important, why the tuples are not? var tuple1: (Int, Int) = (0, 0) var tuple2: Int, Int = (0, 0) type(of: tuple1) == type(of: tuple2)// true var void: ((())) = () type(of: void) == type(of: Void()) // true 2017-06-07 10:15 GMT+08:00

Re: [swift-evolution] Proposal: Always flatten the single element tuple

`((Int, Int)) -> Void` will be same type as `(Int, Int) -> Void` 2017-06-07 18:09 GMT+08:00 Adrian Zubarev : > Keep in mind there is also SE–0111 cometary which promises sugar for > parameter labels for closures: > > // ** > let foo(tuple:): ((Int, Int)) -> Void

Re: [swift-evolution] Proposal: Always flatten the single element tuple

Replacement for fn4 is just make a tuple inside the closure let workWithTuple: (Int, Int) -> Void = { doSomething(withTuple: ($0, $1)) } 2017-06-07 18:03 GMT+08:00 Adrian Zubarev : > Well please no: > > let fn2: ((Int, Int)) -> Void = { lhs, rhs in } > > Instead

Re: [swift-evolution] Proposal: Always flatten the single element tuple

; >>> The question is how to accommodate some common use cases for >>> destructuring as a matter of syntactic sugar after having carefully >>> distinguished argument lists and tuples in the compiler, which is a given, >>> not how to roll back a change that was settled

Re: [swift-evolution] Proposal: Always flatten the single element tuple

> [(1, 2)].map({ tuple in tuple.0 + tuple.1 }) // this line should not >>> accepted >>> > >>> > or >>> > >>> > [(1, 2)].map({ $0 + $1 }) // this line is correct >>> > [(1, 2)].map({ $0.0 + $0.1 }) // this line should not accept

Re: [swift-evolution] Proposal: Always flatten the single element tuple

he function case? > > > > func add(_ x: Int, _ y: Int) -> Int { > > return x + y > > } > > [(1, 2)].map(add) > > > > Where does `map` with a function of `((Int, Int)) -> Int` fit in? > > > > > On Jun 6, 2017, at 10:15

Re: [swift-evolution] Proposal: Always flatten the single element tuple

a PR is create: https://github.com/apple/swift-evolution/pull/722 2017-06-07 10:15 GMT+08:00 Susan Cheng : > Introduction > > Because the painful of SE-0110, here is a proposal to clarify the tuple > syntax. > > Proposed solution > 1. single element tuple always be

Re: [swift-evolution] Proposal: Always flatten the single element tuple

t { > return x + y > } > [(1, 2)].map(add) > > Where does `map` with a function of `((Int, Int)) -> Int` fit in? > > > On Jun 6, 2017, at 10:15 PM, Susan Cheng via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Introduction &

Re: [swift-evolution] Proposal: Always flatten the single element tuple

gt; Int { >> return x + y >> } >> [(1, 2)].map(add) >> >> Where does `map` with a function of `((Int, Int)) -> Int` fit in? >> >> > On Jun 6, 2017, at 10:15 PM, Susan Cheng via swift-evolution < >> swift-evolution@swift.org> wrote: &

[swift-evolution] Proposal: Always flatten the single element tuple

Introduction Because the painful of SE-0110, here is a proposal to clarify the tuple syntax. Proposed solution 1. single element tuple always be flattened let tuple1: (((Int))) = 0 // TypeOf(tuple1) == Int let tuple2: Int))), Int) = (0, 0) // TypeOf(tuple2) == (Int, Int) 2. function

Re: [swift-evolution] [Proposal]Allow constraints on associatedtype and shorten type constraints list in function

Powerful Constraints for Associated Types > > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016354.html > > > > Regards, > Anders > > > On 29 Jul 2016, at 10:17 AM, Susan Cheng via swift-evolution < > swift-evolution@swift.org > <javascri

[swift-evolution] [Proposal]Allow constraints on associatedtype and shorten type constraints list in function

Hello swift community, I want to introduce a proposal to allow constraints on associatedtype. I found a bug report(https://bugs.swift.org/browse/SR-1466) and it's due to without constraints on associatedtype itself. This force us always have to write the redundant constraints like

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

I forgot to reply, a shared value type can capture by multiple closures. func twoThreads() -> (Thread, Thread) { var shared_int = 0 return (Thread { shared_int = 1 }, Thread { shared_int = 2 }) } Johannes Neubauer 於 2016年7月18日星期一 寫道： > > > Am 18.07.2016 um 06:47

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

so, you want to propose default == operator but not forbidding all peoples to custom == operator? Why don't just adding the following function to std library? public func == (lhs: T, rhs: T) -> Bool { var lhs = lhs var rhs = rhs return memcmp(, , sizeof(T.self)) == 0 } Thread

Re: [swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

How about Polar(r: 0, phi: 0) ? It should all equal with any angles if r == 0. 2016-07-16 0:41 GMT+08:00 Johannes Neubauer via swift-evolution < swift-evolution@swift.org>: > > > Am 15.07.2016 um 18:29 schrieb Saagar Jha : > > > > Here's a value type that uses custom

[swift-evolution] [Proposal]Simple pattern matching with Horspool algorithm

public extension CollectionType where Index : RandomAccessIndexType { @warn_unused_result func matchWith(pattern: C, @noescape isEquivalent: (Generator.Element, Generator.Element) throws -> Bool) rethrows -> Index? { let pattern_count = pattern.count.toIntMax() if

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

t;U) -> (T, T) -> > Bool { > return { getComparisonKey($0) < getComparisonKey($1) } > } > > peoples.sort(byComparing { $0.name }) > > ? > > -Dave > > On Dec 30, 2015, at 10:38 PM, Susan Cheng via swift-evolution < > swift-evolution@swift.

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

;dabrah...@apple.com> 於 2015年12月31日星期四 寫道： >> >>> Why add all those algorithms when you can write this >>> >>> func byComparing<T, U: Comparable>(getComparisonKey: (T)->U) -> (T, T) >>> -> Bool { >>> return { getComparisonKe

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

gt; On Wed, Dec 30, 2015 at 10:38 PM, Susan Cheng via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote: > >> >> Consider the follows: >> >> >> struct Person { >> >> >>

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

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

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

[swift-evolution] About the PermutationGenerator

PermutationGenerator confuses me that it's confirm to both of SequenceType and GeneratorType. Should it replace by PermutationSequence and PermutationGenerator? Also, we should have a PermutationCollection because we can: public struct PermutationCollection : CollectionType { public

[swift-evolution] missing proposal about missing @noescape of 'SequenceType.flatMap'

Hi, I found the thread about missing attribute @noescape of 'SequenceType.flatMap' but it doesn't have a proposal in swift-evolution: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001025.html Susan ___ swift-evolution mailing

Re: [swift-evolution] Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib

Consider this: extension CollectionType where Generator.Element : Equatable { /// Returns a subsequence, until a element equal to `value`, containing the /// initial elements. /// /// If none of elements equal to `value`, the result contains all /// the elements of `self`.

Re: [swift-evolution] Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib

Consider: extension CollectionType where Generator.Element : Equatable { /// Returns a subsequence, until a element equal to `value`, containing the /// initial elements. /// /// If none of elements equal to `value`, the result contains all /// the elements of `self`. ///

Re: [swift-evolution] Coroutine for Swift

> >> Generators are one use case, but resumable functions in general can also >> be used to make async code look prettier. >> >> Félix >> >> Le 22 déc. 2015 à 01:47:05, Susan Cheng via swift-evolution < >> swift-evolution@swift.org> a écrit : >&

[swift-evolution] Fwd: Coroutine for Swift

outines in Swift too. The feature has been very >> successful in other languages like Python and C#, and unless I'm mistaken, >> work is being done to standardize it in C++. >> >> Generators are one use case, but resumable functions in general can also >> be used to

[swift-evolution] Coroutine for Swift

here is my proposal for swift lang https://github.com/SusanDoggie/swift-evolution/blob/master/proposals/0018-coroutine-for-swift.md ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution