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

> On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution > wrote: > > I think we have different definitions of consistency. I am fine with the > ergonomics of (0…100).random() as a convenience, but it really worries me > here that everything is special

Re: [swift-evolution] [pitch] adding toggle to Bool

> On Jan 12, 2018, at 12:15 AM, Chris Eidhof via swift-evolution > wrote: > > Hey SE! > > When we have a bunch of nested structs: > > struct Sample { > var bar: Bar > } > > struct Bar { > var show: Bool > } > > var foo

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

pain in that case, so you could either write `UInt64.random(in: .min ... .max)` or else access data from whatever generator you’re using—`Random.default.next()`. Also, from a discoverability and documentation perspective, I like having static `random` methods on the types that they generate.

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

res the appropriate state >> >> That’s neat, I’ve never used a generator like this! The >> RandomNumberGenerator protocol would certainly allow for a generator with >> these features, and libraries or future additions to the standard library >> could include

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 9, 2018, at 11:00 AM, Gwendal Roué via swift-evolution > wrote: > >> >> Le 9 janv. 2018 à 17:16, Zach Waldowski via swift-evolution >> > a écrit : >> >> I'm not sure a valid use case by a third

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

) method which takes a token and > restores the appropriate state That’s neat, I’ve never used a generator like this! The RandomNumberGenerator protocol would certainly allow for a generator with these features, and libraries or future additions to the standard library could include that kind of

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

Nate > On Jan 9, 2018, at 12:12 AM, Chris Lattner via swift-evolution > wrote: > > >> On Jan 8, 2018, at 4:29 PM, Ben Cohen via swift-evolution >> wrote: >> There exists in the standard library a type `DictionaryLiteral` that >>

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

superior to the alternatives in essentially every respect. In > the alternative, maybe "KeyValueLiteral" or something of that sort, but I > still would consider that to be strictly inferior to "DictionaryLiteral". > > >> On Mon, Jan 8, 2018 at 20:24 N

Re: [swift-evolution] 100% bikeshed topic: DictionaryLiteral

> On Jan 8, 2018, at 6:29 PM, Ben Cohen via swift-evolution > wrote: > > There exists in the standard library a type `DictionaryLiteral` that deserves > naming re-consideration before we declare ABI Stability, because it’s > confusingly misnamed, being neither a

Re: [swift-evolution] Proposal: Add a sequence-based initializer to Dictionary

Hi Gregg — The Dictionary(_:uniquingKeysWith:) initializer was added for this purpose in Swift 4—please see https://developer.apple.com/documentation/swift/dictionary/2892961-init Nate > On Jan 8, 2018, at 1:02 PM, Gregg Wonderly via swift-evolution > wrote: > >

Re: [swift-evolution] why cant you initialize BinaryFloatingPoint from BinaryInteger?

Right, SE-0067 included that initializer with the caveat that implementation wouldn't be possible until the integer protocols were revised. As far as I can see, that makes this a fix that wouldn't need further SE discussion. (The generic init(exactly:) needs an implementation, too.)

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

> On Nov 30, 2017, at 6:20 PM, Xiaodi Wu wrote: > > On Thu, Nov 30, 2017 at 5:24 PM, Nate Cook wrote: >>> On Nov 30, 2017, at 4:30 PM, Xiaodi Wu via swift-evolution >>> wrote: >>> On Thu, Nov 30, 2017 at 3:58 PM, Dave

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

> On Nov 30, 2017, at 4:30 PM, Xiaodi Wu via swift-evolution > wrote: > > On Thu, Nov 30, 2017 at 3:58 PM, Dave DeLong via swift-evolution > > wrote: > > >> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via

[swift-evolution] [draft] Add last(where:) and lastIndex(where:) Methods

Hello, Swift Evolution! This is a revision of a previous proposal for adding methods to sequences/collections for searching from the end. Feedback welcome! Nate — Add last(where:) and lastIndex(where:) Methods Proposal: SE- Author: Nate Cook

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

> On Nov 15, 2017, at 10:24 PM, Alejandro Alonso wrote: > > I wrote up a quick and dirty example displaying Randomizable in action > working alongside Strideable > https://gist.github.com/Azoy/30d2554d11a3fb8f770e3b310fb47aca >

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

> On Nov 12, 2017, at 7:47 PM, Alejandro Alonso wrote: > > Sorry I’ve been gone for a while, I had to do a lot of traveling. > > 1. Initially I made this thinking that developers had the power to determine > their own lower bound. The current implementation uses the

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

> On Nov 13, 2017, at 7:38 PM, Xiaodi Wu wrote: > > On Mon, Nov 13, 2017 at 7:12 PM, Alejandro Alonso > wrote: > After thinking about this for a while, I don’t agree with with an associated > type on

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-188 Make stdlib index types Hashable

Thanks for this, Brent, you make a strong case! I didn't include a change to Collection.Index simply because it doesn't look like missing the constraint is really causing harm, just inconvenience. That said, you’re right that making something Hashable is easier than ever, and if we’re going to

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

Thanks for continuing to push this forward, Alejandro! I’m excited about the potential of having access to these APIs as part of the standard library. Here are a few comments on some different parts of the proposal: 1) For your RandomGenerator protocol, I’m not totally clear on the semantics of

[swift-evolution] [draft] Make Standard Library Index Types Hashable

Hello! I’d like to propose adding Hashable conformance to the standard library’s index types, making subscripts in key path expressions more useful with the standard library’s collections. Note that this will not affect the requirements for Collection’s associated Index type, only concrete

Re: [swift-evolution] [Draft] Rename Sequence.elementsEqual

> On Oct 13, 2017, at 9:59 AM, Xiaodi Wu via swift-evolution > wrote: > >> On Fri, Oct 13, 2017 at 09:02 Adam Kemp wrote: >> Right, but if you do look it up you get a bunch of things talking about >> sorting words. > > And that’s a perfect

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

ft-evolution@swift.org <mailto:swift-evolution@swift.org>> escribió: > >> I agree with Ben here because users can still enter an invalid range with >> the static function. I.E. Int.random(in: 0 ... 0). >> I would really prefer excluding these static functions from numer

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

> On Oct 5, 2017, at 11:30 AM, Ben Cohen via swift-evolution > wrote: > >> On Oct 4, 2017, at 9:12 PM, Chris Lattner via swift-evolution >> > wrote: >> >>> ``` >>> extension Int { >>> static func

Re: [swift-evolution] Revisiting SE-0110

> Joe Groff wrote: > > Furthermore, this probably comes up most commonly with dictionaries, since > they're a sequence of tuples. The element tuple for dictionaries has element > labels (key: Key, value: Value), so instead of writing `{ tuple in let (key, > value) = tuple; f(key, value) }`,

Re: [swift-evolution] SE-165: Dictionary & Set Enhancements

> On Apr 5, 2017, at 9:43 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 5, 2017, at 5:45 PM, Ben Cohen via swift-evolution >> > wrote: >> >> • What is your evaluation of the

Re: [swift-evolution] [Draft] Dictionary & Set Enhancements

Yep, here it is -- didn't realize the length would cause such problems! https://gist.github.com/natecook1000/4bd8f20736eb99ed3c5a4cdcc41e9a5f Nate > On Apr 1, 2017, at 12:01 PM, Jason Gregori via swift-evolution > wrote: > > I really like the merging

Re: [swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

have a sense of how frequently type-level expressions are used in default parameters? As far as I've seen the standard library only uses literals. A change to this behavior would be source-breaking, but perhaps not painfully so. Nate > On Feb 22, 2017, at 12:16 PM, Nate Cook via swift-evolut

Re: [swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

Oops, left out that there's this horrifying way of writing it right now: extension Collection { func index(_ i: Index! = nil, offsetBy n: IndexDistance) -> Index { let i = i ?? startIndex // ... } } Nobody wants that. ___

[swift-evolution] [Pitch/Reality Check] Allow instance members as parameter default values

Hello all, I was surprised to find that I can't use an instance member as the default value of a method parameter, only constants and the run-time calculated #file, #line, etc. Is it possible to remove this limitation? I'd like to propose that we add an overload of the collection

Re: [swift-evolution] Dictionary Enhancements

> On Feb 19, 2017, at 6:13 PM, Ben Cohen via swift-evolution > wrote: > >> On Feb 19, 2017, at 11:22 AM, Ole Begemann > > wrote: >> >>> On 17 Feb 2017, at 01:26, Ben Cohen via swift-evolution >>>

Re: [swift-evolution] Dictionary Enhancements

Hi Jon, Thank you for the feedback, this is really valuable! A couple questions below. > On Feb 17, 2017, at 8:50 PM, Jonathan Hull via swift-evolution > wrote: > > Thoughts inline. > >> On Feb 16, 2017, at 4:26 PM, Ben Cohen via swift-evolution >>

Re: [swift-evolution] Strings in Swift 4

With a lot of these new features, it helps me greatly to see them in action. I've built a poor man's version of these incomplete ranges in a Swift Sandbox here: http://swiftlang.ng.bluemix.net/#/repl/58925f5d42b65e6dce9a5bea This implementation suffers greatly from a lack of generic

Re: [swift-evolution] [Proposal] Add Array binary search to the standard library

> On Jan 30, 2017, at 2:47 AM, Alexey Komnin via swift-evolution > wrote: > > Hello to everyone. > > Let me put my two cents. > >>> I didn’t want the SortedArray to conform to MutableCollection or >>> even RandomAccessCollection as I felt it was not needed just to

Re: [swift-evolution] Strings in Swift 4

> On Jan 30, 2017, at 8:51 AM, Thorsten Seitz via swift-evolution > wrote: > >> Am 23.01.2017 um 02:14 schrieb James Froggatt via swift-evolution >> : >> >> Could we add subscript labels to the list of options? While keeping the >> range

Re: [swift-evolution] [Discussion] mailing list alternative

> On Jan 26, 2017, at 1:41 PM, Dave Abrahams via swift-evolution > wrote: > > It's a shame that it has no facility for hiding long quotations. Trying > to find the actual content in this thread is pretty awful: >

Re: [swift-evolution] [Discussion] mailing list alternative

> On Jan 25, 2017, at 3:32 PM, Douglas Gregor via swift-evolution > wrote: > >> >> On Jan 25, 2017, at 12:05 PM, Ted Kremenek via swift-evolution >> > wrote: >> >> I have no problem with the project

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

> On Dec 2, 2016, at 2:12 PM, Ben Cohen via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > >> On Dec 1, 2016, at 11:33 PM, Nate Cook via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift

Re: [swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

> On Nov 30, 2016, at 6:15 PM, Dave Abrahams via swift-evolution > wrote: > > on Wed Nov 30 2016, Kevin Ballard > wrote: > >> This sounds like a sensible idea. But there is one behavioral change you >>

[swift-evolution] [Pitch] Normalize Slice Types for Unsafe Buffers

Hello all— This is a proposal for a fairly minor change in slicing behavior for unsafe buffers. Nate -- This proposal changes Swift's typed UnsafeBufferPointers to be their own slice type, like the UnsafeRawBufferPointer types. This is a minor change in the subscript API of

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

> On Oct 13, 2016, at 1:28 AM, Dave Abrahams via swift-evolution > wrote: > > on Wed Oct 12 2016, Nate Cook > wrote: > >>> On Oct 12, 2016, at 9:32 AM, plx via swift-evolution >>>

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

ot the intended behavior, right? Ha, no! Thanks for the bug report. :) See my response here for more about COW: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161010/027866.html Nate >> On 2016-10-11, at 23:28, Nate Cook via swift-evolution >> <swift-evolution@s

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

where “maybe the optimizer can be made smarter” > can cut it; I want performance guarantees, not hopes). > >> On 11 Oct 2016, at 23:28, Nate Cook via swift-evolution >> <swift-evolution@swift.org> wrote: > > [snip] > > On a shallow read I like presented

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

> On Oct 12, 2016, at 9:32 AM, plx via swift-evolution > wrote: > > The issue addressed is real; I’m not sure this is the best approach. > > In particular, unless I’m missing something obvious, the ownership strategy > here would have to be: > > -

Re: [swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

PM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Very elegant solution. Strong +1; no other feedback comes to mind atm. >> >> >> On Tue, Oct 11, 2016 at 4:28 PM, Nate Cook via swift-ev

[swift-evolution] [Proposal Draft] Provide Custom Collections for Dictionary Keys and Values

Introduction This proposal addresses significant unexpected performance gaps when using dictionaries. It introduces type-specific collections for a Dictionary instance's keys and values properties. New DictionaryKeys and DictionaryValues collections provide efficient key lookup and mutable

Re: [swift-evolution] [Proposal draft] Disallow Optionals in String Interpolation Segments

> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution > wrote: > > On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote: >>> >>> ... >>> >> We had this at one point, but we took it out because people would forget to >> test the nil case. I think `?? ""` or

Re: [swift-evolution] [Review] SE-0142: Permit where clauses to constrain associated types

> https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md > What is your evaluation of the proposal? [Smiling Face With Heart-Shaped Eyes Emoji] One of the examples given (associatedtype SubSequence : Sequence where SubSequence...) looks like it

Re: [swift-evolution] [SHORT Review] SE-0132: Rationalizing Sequence end-operation names

> > https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md First, a big thanks to Brent for all the work in categorizing, describing, and justifying all these changes! I'm largely in favor of the new method names—several of the renamings lead to better

Re: [swift-evolution] [Review] SE-0131: Add AnyHashable to the standard library

> > https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md +1! This proposal looks great to me. I only have one nitpick: it looks like there's a '_Hashable' protocol used in the Dictionary extension to get around the limit on generic subscripts. Swift has

Re: [swift-evolution] [Review] SE-0120: Revise 'partition' Method Signature

> On Jul 12, 2016, at 7:06 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue Jul 12 2016, Jacob Bandes-Storch > wrote: > >>> >>> Proposal link: >>> >>>

Re: [swift-evolution] Dropping Comparable requirement for indices

> On Jul 5, 2016, at 9:39 PM, Dave Abrahams via swift-evolution > wrote: > > I've already raised the question here of whether we should weaken the > requirement that Collection.Index be Comparable to merely being > Equatable. > > Part of the motivation was to

[swift-evolution] [Draft] Fix the Collection Partition API

Hi all, This is a crack at a proposal to revise the API of the collection partition method, called out as an open issue in the standard library. What's below is a much shorter revision of a prior proposal, focused only on the partition method. I welcome any feedback you might have! Thanks,

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

Nate > On Jun 28, 2016, at 3:57 PM, Dave Abrahams via swift-evolution > wrote: > > >> on Thu Jun 23 2016, Nate Cook wrote: >> >> I like the namespace-based approach to group these protocols together >> and I'm very happy to see some

Re: [swift-evolution] [Proposal Draft] Literal Syntax Protocols

I like the namespace-based approach to group these protocols together and I'm very happy to see some clarification happening in this group of protocols. However, I don't think the proposed new names communicate what they need to. The names listed in the "Alternatives Considered" section do a

Re: [swift-evolution] Swift 3 vs "additive" proposals

> On Jun 22, 2016, at 9:59 AM, Erica Sadun via swift-evolution > wrote: > >> On Jun 21, 2016, at 11:55 PM, Chris Lattner via swift-evolution >> > wrote: >> >> Hi Everyone, >> >> As I mentioned before, the

Re: [swift-evolution] Proposal: Filter split extension on Sequence to return tuple of sequences that meet criteria and that do not

> On Jun 8, 2016, at 3:40 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Jun 08 2016, Dave Abrahams wrote: > >> on Wed Jun 08 2016, gadiraju praneeth wrote: >> >>> Many times, I came across a

Re: [swift-evolution] [Pitch] Renaming sizeof, sizeofValue, strideof, strideofValue

I'd like to cast another vote in favor of something like the MemoryLayout struct. In general, people aren't always making the right choice about which of these values to use. Combining them into one data type would mean they see that there are three related values and can find out when to use

Re: [swift-evolution] [Pitch] Add `mapValues` method to Dictionary

> On May 26, 2016, at 4:23 PM, Dave Abrahams via swift-evolution > wrote: > > > on Tue May 24 2016, Nate Cook wrote: > >>> On May 24, 2016, at 7:43 AM, Matthew Johnson via swift-evolution >>> wrote: >>> >>>

Re: [swift-evolution] [Pitch] Add `mapValues` method to Dictionary

> On May 24, 2016, at 7:43 AM, Matthew Johnson via swift-evolution > wrote: > > Sent from my iPad > > On May 24, 2016, at 12:59 AM, Brent Royal-Gordon via swift-evolution > wrote: > >>> I have a small remark though, wouldn’t it be

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections

> On May 17, 2016, at 5:18 PM, Luis Henrique B. Sousa via swift-evolution > wrote: > > Many thanks, @Maximilian. I'm also not sure about the performance cost, but I > think it is worth it. > So I just updated the proposal also including the additional min/max you

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

>> On May 13, 2016, at 9:36 AM, Dave Abrahams via swift-evolution >> wrote: >> >> on Mon May 09 2016, Nate Cook wrote: >> >> Yet another alternative would be to drop Set and Dictionary down a >> level to a FiniteSequence protocol in between Sequence and >>

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

> On May 11, 2016, at 12:32 PM, Hooman Mehr via swift-evolution > wrote: > > Thank you for your comments. > > I think additional index manipulation and collection scanning API is needed, > and your proposal cover an important part of it. > > I also have some

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

d the alternative explained. These return nil when no matching element is found, just like their from-the-beginning counterparts. endIndex would not be appropriate as a return value. > On May 10, 2016, at 13:54, Nate Cook via swift-evolution > <swift-evolution@swift.org <mailto:swift-

Re: [swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

to see if / how a proposal could use those in a generic context. Thanks again! Nate > Look at the comments for the example usage. For `offset` function, see the > source code for usage. > > Hooman > >> On May 10, 2016, at 11:54 AM, Nate Cook via swift-evolution >> <sw

[swift-evolution] (Draft) Add last(where:) and lastIndex(where:) methods

I've needed these in the past and used them in other languages—any feedback on this idea? Add last(where:) and lastIndex(where:) Methods to Bidirectional Collections The standard library should include methods for finding the last element of a bidirectional collection that matches a predicate,

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

> On May 9, 2016, at 9:48 PM, Joe Groff via swift-evolution > wrote: > >> >> On May 9, 2016, at 6:23 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >>> * Operations that depend on sorted-ness and use binary predicates should >>>

Re: [swift-evolution] [Review] SE-0074: Implementation of Binary Search functions

>> Proposal: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0074-binary-search.md >> >> > On May 6, 2016, at 5:16 PM, Dave Abrahams via swift-evolution >

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

> On May 6, 2016, at 4:20 PM, Dave Abrahams via swift-evolution > wrote: > >> on Fri May 06 2016, Nate Cook wrote: >> >>How can you reverse a variable-length collection with a fixed number of >>iterations? Are you talking about loop unrolling in the

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

> On May 6, 2016, at 12:35 AM, Dmitri Gribenko wrote: > > On Thu, May 5, 2016 at 5:11 PM, Nate Cook > wrote: >> Thanks for the feedback, Dmitri , this all looks excellent! I'll work on >> updating the proposal. >> >>> On

Re: [swift-evolution] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

> On May 3, 2016, at 11:51 PM, Xiaodi Wu via swift-evolution > wrote: > >> * What is your evaluation of the proposal? > > +1. A very useful function to have on collections. > > In FORTRAN and in languages that take inspiration from it, the same function >

Re: [swift-evolution] Eliminate inconsistencies among primary collection types

> On Apr 29, 2016, at 1:57 PM, Wolfgang H. via swift-evolution > wrote: > > Inconsistency A. is that “Set” currently is the only collection type > conforming to protocol 'Hashable'”. IMHO both “Array” and “Dictionary” should > conform to protocol “Hashable”, too.

Re: [swift-evolution] Mutability for Foundation types in Swift

This looks amazing—really looking forward to seeing the progression here! I do have a question about how copy-on-write is handled for larger data types like Data (née NSData). The standard library types that can use bridged storage use immutable classes until there's a mutation, at which point

[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

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 12, 2016, at 4:15 AM, Dmitri Gribenko via swift-evolution > wrote: > > On Mon, Apr 11, 2016 at 9:56 PM, Brent Royal-Gordon via > swift-evolution wrote: >> (On the other hand, it might be that I'm conceiving of the purpose of >>

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On Apr 11, 2016, at 6:49 PM, Dave Abrahams via swift-evolution > wrote: > > on Mon Apr 11 2016, Ross O'Brien wrote: > >> I think I'd like to +1 a 'for x in loop(from: while: next:)'. (Possibly >> 'iterate' rather than 'loop'?) > >