Re: [swift-evolution] FloatingPoint does not conform to ExpressibleByFloatLiteral

I’m with Nevin on this one. Perhaps the easiest thing to do is to add something to the FloatLiteral type that lets you get it as a string if desired. Didn’t we have a discussion a while back on how to make Integer Literals work with BigInt? Maybe there is an idea from that discussion that woul

Re: [swift-evolution] [Pitch] Percentage Type

If you look at the implementation I provided, it allows for percentages higher than 100% (and has an easy way to clip them or map them to an arbitrary range). > On Jan 16, 2018, at 11:39 AM, Dave DeLong via swift-evolution > wrote: > > > >> On Jan 16, 2018, at 9:56 AM, Jon Gilbert via swift

Re: [swift-evolution] [Pitch] Percentage Type

y available in the form of > Foundation.Decimal on all supported platforms. > > On Sat, Jan 13, 2018 at 9:07 PM, Jonathan Hull via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Here is the code I use for percentage myself. (I incorrectly said I use a >

Re: [swift-evolution] [Pitch] Percentage Type

static func * (lhs:Num, rhs:Percentage)->Num { return lhs * rhs.numValue } static func * (lhs:Percentage, rhs:Percentage)->Percentage { return Percentage(lhs.decimalValue * rhs.decimalValue) } } > On Jan 13, 2018, at 6:26 PM, Jonathan Hull vi

[swift-evolution] [Pitch] Angle Type

Hi Evolution, I would really like to see Swift gain an Angle type in the standard library. Every time I have to deal with an angle in an api, I have to go figure out the conventions for that call. Is it in degrees? Is it in radians? What if it is in radians, but I want to think about it in d

[swift-evolution] [Pitch] Percentage Type

Hi Evolution, I was wondering if we would consider adding a percentage type to Swift. This would be a type with a value between 0 & 1. I know we can and do use doubles or floats for this now, but there really is a semantic difference between most parameters that take a value between 0 & 1 and

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

> On Jan 12, 2018, at 8:22 PM, Nate Cook wrote: > > On Jan 12, 2018, at 6:24 PM, Jonathan Hull via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> I think we have different definitions of consistency. I am fine with the >> ergonomics of

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

Basically, my point is that I want to be able to operate generically. > On Jan 13, 2018, at 5:20 AM, Letanyan Arumugam wrote: > > >> On 13 Jan 2018, at 02:24, Jonathan Hull > > wrote: >> >> I think we have different definitions of consistency. I am fine with the >> erg

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

> On Jan 13, 2018, at 5:20 AM, Letanyan Arumugam wrote: > > >> On 13 Jan 2018, at 02:24, Jonathan Hull > > 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

Re: [swift-evolution] Handling unknown cases in enums [RE: SE-0192]

I’m definitely in the error camp, but I will go along with a warning if everyone feels that is better. Thanks, Jon > On Jan 12, 2018, at 3:08 PM, Jordan Rose via swift-evolution > wrote: > > Okay, I went back to `unknown case` in the proposal, but mentioned Chris's > point very specifically:

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

> On Jan 12, 2018, at 4:24 PM, Jonathan Hull wrote: > > Or what if I want an effect where it randomly fades in letters from a String. Just to explain this example further. I ran into this issue when trying to use arc4random to do this. The eye is really sensitive to patterns in cases like t

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

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 cased. Special cased things are fine for individual projects, but not the standard library. We should make sure th

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

We are doing crazy contortions to avoid the 'random % 100’ issue. Why not just check for that pattern and issue a warning with a fixit to do it better? I don’t think it is worth handicapping everything just to avoid this. Thanks, Jon > On Jan 11, 2018, at 11:22 PM, Nate Cook via swift-evoluti

Re: [swift-evolution] [Proposal] Revamp the playground quicklook APIs

> On Jan 11, 2018, at 11:22 AM, Connor Wakamo via swift-evolution > wrote: > > That’s very reasonable. I’ll update the proposal to use > CustomPlaygroundConvertible (unless I or someone else can come up with a > really good “Thing” for a name like CustomPlaygroundThingConvertible, as that >

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

> On Jan 10, 2018, at 4:42 PM, Nate Cook wrote: > > I don’t see how a single distribution would generate both integers and > colors. Can your color type be initialized from an integer? Since the > “distributions” in that playground are just sequences, you could add > .lazy.map({ Color(value:

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

> On Jan 10, 2018, at 4:42 PM, Nate Cook wrote: >> Right. I guess my thought is that I would like them to be able to use a >> standard creation pattern so it doesn’t vary from type to type (that is the >> whole point of “unification” in my mind). In my own code, I have a concept >> of constra

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

> On Jan 9, 2018, at 8:28 AM, Nate Cook wrote: > >> On Jan 9, 2018, at 4:12 AM, Jonathan Hull > > wrote: >> >> Some thoughts: >> >> - How do I randomly select an enum? > > Vote for SE-0194! :) > >> - I like that RandomNumberGenerator doesn’t have an associated type. I

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

Some thoughts: - How do I randomly select an enum? - I like that RandomNumberGenerator doesn’t have an associated type. I agree that we should just spit out UInt64s for simplicity. - I don’t like how it is so closely tied with Range. I realize that both Int and Float work with Ranges, but oth

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Oh, I see… the case would silently change from unexpected to default if they were both included. Hmm. I will have to think on this more. Thanks, Jon > On Jan 5, 2018, at 3:17 PM, Jordan Rose wrote: > > > >> On Jan 5, 2018, at 00:11, Jonathan Hull via swift-evolutio

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 4, 2018, at 11:02 PM, Xiaodi Wu wrote: > > > On Fri, Jan 5, 2018 at 01:56 Jonathan Hull > wrote: >> On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: > >> >> On Fri, Jan 5, 2018 at 00:21 Cheyo Jimenez >

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Jan 5, 2018 at 00:21 Cheyo Jimenez > wrote: > > On Jan 4, 2018, at 4:37 PM, Xiaodi Wu > wrote: > >> On Thu, Jan 4, 2018 at 19:29 Cheyo J. Jimenez >

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

I think there are a couple of different definitions running around, and that is confusing things. In my mind, ‘unexpected:’ catches only cases which were unknown at compile time. Adding cases to an enum *should* be a source-breaking change. That is the whole point of this. We should have to up

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

I think this is a good summary. I agree that we need to handle unexpected cases from changes to a binary somehow. The main issue is that, when forcing developers to use ‘default’ to do it, it also brings along unwanted semantics that prevent warnings in the very common use case of a 3rd part

Re: [swift-evolution] Happy new year Swift community.

Happy New Year! > On Dec 31, 2017, at 6:01 PM, Goffredo Marocchi via swift-evolution > wrote: > > Happy new year everybody :)! > > Sent from my iPhone > > On 31 Dec 2017, at 23:43, David Hart via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> Thank you very much and happy

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 21, 2017, at 11:07 AM, Jordan Rose wrote: > > Thanks for your comments, Jon. Responses inline. > >> On Dec 20, 2017, at 12:46, Jonathan Hull > > wrote: >> >> >>> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >>> mailto:swift-evolution@swift.org

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

+1 for @frozen > On Dec 20, 2017, at 7:16 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution >> wrote: >> >> • What is your evaluation of the proposal? > > I am pleased with the broad strokes of this design. I have qui

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek via swift-evolution > wrote: > When reviewing a proposal, here are some questions to consider: > > What is your evaluation of the proposal? > Strong -1 as is. I think I would support having an explicit ‘futureCase’ which is different from ‘default’

Re: [swift-evolution] Proposal and Timeline for Discourse Transition

I would also like a place in the “Using Swift” for working on libraries or open source projects. I think asking for collaborators is fundamentally different than asking technical questions. It would be nice to have support somehow for the idea of working groups for evolution > On Dec 12, 2017

Re: [swift-evolution] Optional Argument Chaining

+1 to this. I also like Adrian’s notation where the ? is after the name, but before the parameter list. > On Dec 12, 2017, at 7:33 AM, Yuta Koshizawa via swift-evolution > wrote: > > I think evaluating them in the same way as `try` calls is consistent. > > ``` > f(g()?, h()?, i(), j()?)? > /

Re: [swift-evolution] Optional Argument Chaining

In my opinion, simple left to right evaluation where it short circuits on the first failure is the simplest. But I don’t think it matters that much as long as we have a consistent way to define it, and explain it. It is nice to have forward transfer from other features, but sometimes we just n

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On Nov 14, 2017, at 9:06 PM, Brent Royal-Gordon via swift-dev > wrote: > >> On Nov 14, 2017, at 5:21 PM, Xiaodi Wu > > wrote: >> >> 1. It must be possible to easily access the count of values, and to access >> any particular value using contiguous `Int` indices.

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Ok, I have changed my mind about the need for a marker, and will accept the proposal as-is. I realized that these dynamic member lookup types can just be made inner types, and so I can easily create the .dynamic behavior in my own code if I want under the current proposal. I also realized that

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

> On Dec 3, 2017, at 9:39 AM, Chris Lattner wrote: > > On Dec 3, 2017, at 5:45 AM, Jonathan Hull > wrote: >> Hi Chris, >> >> I am definitely in favor of providing dynamic features in Swift, and of >> being able to interoperate easily with dynamic languages. I really lik

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Hi Chris, I am definitely in favor of providing dynamic features in Swift, and of being able to interoperate easily with dynamic languages. I really like the idea overall. I was about to write up a different idea I had for partially mitigating some of the issues around being able to mistype me

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

> On Dec 1, 2017, at 9:39 AM, Martin Waitz wrote: > > Hi, > >> With a protocol defining random() and random(in:), you could write generic >> algorithms on things which know how to create themselves from a RNG. With >> your approach the RNG has to provide a way to get a random value for each

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

> On Nov 30, 2017, at 11:11 PM, Martin Waitz wrote: > > Hello, > >> The collection is a subject which has elements, and we are asking for one of >> them at random. > > it has elements, sure. > And because of its structure, it has a first and a last element and whatever. > But that random elem

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

0, 2017 at 3:58 PM, Dave DeLong via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> I would p

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

> On Nov 30, 2017, at 3:46 PM, Martin Waitz wrote: > > Hello Jonathan, > >> For collections, I think we should call returning a random element >> -randomElement, and choosing a random element without replacement >> -popRandomElement > > I disagree because I don’t think that the random data is

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

> On Nov 30, 2017, at 3:52 PM, Dave DeLong wrote: > > What is the useful distinction between generating a random value, and > choosing a random element from a collection of all possible values? I don’t have to generate (or keep in memory) that collection. I gave an example before of an easy

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

te: >>> >>> >>> >>>> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution >>>> mailto:swift-evolution@swift.org>> wrote: >>>> >>>> I would personally go with: >>>> >>>>Int.ran

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

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

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

> suit their needs. > >> 2017/11/30 16:30、Xiaodi Wu > <mailto:xiaodi...@gmail.com>>のメール: >> >> On Thu, Nov 30, 2017 at 3:58 PM, Dave DeLong via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On

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

> On Nov 30, 2017, at 1:58 PM, Dave DeLong wrote: > > > >> On Nov 30, 2017, at 2:48 PM, Jonathan Hull via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I would personally go with: >> >> Int.random //Returns a

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

For collections, I think we should call returning a random element -randomElement, and choosing a random element without replacement -popRandomElement var list = [1,2,3,4] let a:Int? = list.randomElement //List is still [1,2,3,4] and ‘a’ contains one of the elements let b:Int? = list.popRandomE

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

I would personally go with: Int.random //Returns a random Int Int.random(in: ClosedRange) //Works for Comparable types. Gives a result from the closed range. Closed Range is never empty. [0,2,3].randomElement //Returns a random element from the collection Then a version o

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

I noticed all of the examples return the same type as they are defined on (JSON has a subscript that returns JSON). Is there an example of where this is not the case? > On Nov 25, 2017, at 3:16 PM, Chris Lattner via swift-evolution > wrote: > > On Nov 20, 2017, at 10:36 PM, Chris Lattner <

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

+1. It seems like a practical first step. > On Nov 28, 2017, at 10:59 AM, Joe Groff via swift-evolution > wrote: > > > >> On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: >> >> On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: On Nov 20, 2017, at 5:43 PM, Chris Lattner via swif

Re: [swift-evolution] [Pitch] Nested types in protocols (and nesting protocols in types)

I would use this pretty much constantly! I thought it was going to be in Swift 4, and have really been missing it… > On Nov 26, 2017, at 8:51 AM, Adrian Zubarev via swift-evolution > wrote: > > > What happened to this? Should we revive this talk? I’d love to finally be > able to nest proto

Re: [swift-evolution] [Pre-pitch] Conditional default arguments

I have wanted something similar to this for a while, and haven’t suggested it for a while for the same reason… I can’t really think of a good syntax. My best idea so far is to put it after the function declaration but before the open brace: func myCrazyFunction(myParam: T)->Int

Re: [swift-evolution] [swift-evolution-announce] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

What about mapOrNil? > On Nov 21, 2017, at 3:00 PM, Wallacy via swift-evolution > wrote: > > Let’s think I little. If the ideia is choose the best name to explain the > function: > > If the function drop the nil values and after that does a map operation. > Names like dropNilAndMap make sen

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

> On Nov 16, 2017, at 2:23 PM, Ted Kremenek via swift-evolution > wrote: > > When reviewing a proposal, here are some questions to consider: > > What is your evaluation of the proposal? > I think the functionality is good, but I would like to see some thought on what future values could be t

Re: [swift-evolution] [swift-evolution-announce] [Accepted and Focused Re-review] SE-0187: Introduce Sequence.filterMap(_:)

I agree that filterMap is just as confusing and awkward as flatMap, if not more. Filter works on Bools, not nils. It is just asking for trouble/confusion, and I would hate to rename this again next year. If the word ‘filter’ must be used, then I recommend using ‘filteringMap()’ to lessen con

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

Just to play devil’s advocate, wouldn’t they see random(in:) in the autocomplete when typing ‘random’? Thanks, Jon > On Nov 17, 2017, at 3:09 PM, Xiaodi Wu via swift-evolution > wrote: > > On Fri, Nov 17, 2017 at 10:10 AM, Gwendal Roué via swift-evolution > mailto:swift-evolution@swift.org>>

Re: [swift-evolution] update on forum

Glad to see there is progress on this :-) I am hoping, in addition to sections equivalent to the lists, there are areas for working groups on specific topics, and areas for 3rd party frameworks/packages to coordinate/cross-polinate ideas. For example, I have code which I use as a more powerful

Re: [swift-evolution] [pitch] Eliminate Collection.IndexDistance associated type

I guess I am mildly +1. I can’t think of a case where this wouldn’t be some sort of Integer, but I am also open to arguments against. I am not sure what the utility of having a type for this besides Int is... Thanks, Jon > On Nov 8, 2017, at 1:37 PM, Ben Cohen via swift-evolution > wrote: >

Re: [swift-evolution] [Review] SE-0187: Introduce Sequence.filterMap(_:)

> On Nov 7, 2017, at 3:23 PM, John McCall via swift-evolution > wrote: > > When writing your review, here are some questions you might want to answer in > your review: > > • What is your evaluation of the proposal? -1. I am indifferent on the name, but don’t think it is worth the code

Re: [swift-evolution] Large Proposal: Non-Standard Libraries

> On Nov 7, 2017, at 1:58 PM, Ted Kremenek via swift-evolution > wrote: > > We could also figure out a way to possibly highlight these efforts to the > Swift community, maybe on swift-evolution or other means — but all with the > expectation that these libraries are not *necessarily* going to

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

Is there a link to the writeup? The one in the quote 404s. Thanks, Jon > On Nov 5, 2017, at 2:10 PM, Alejandro Alonso via swift-evolution > wrote: > > Hello once again Swift evolution community. I have taken the time to write up > the proposal for this thread, and have provided an implementa

Re: [swift-evolution] Abstract methods

> On Nov 3, 2017, at 10:26 PM, Slava Pestov via swift-evolution > wrote: > >> Probably something like `super` for when you want to override a default >> implementation but still call it: > > This is a good idea. I think it would be pretty straightforward to implement, > and it’s something th

Re: [swift-evolution] stack classes

Could you explain more about your use case? I am not sure I understand the motivation… Also, what are you hoping to dealloc in structs? Thanks, Jon > On Oct 27, 2017, at 6:27 AM, Mike Kluev via swift-evolution > wrote: > > if it wasn't already discussed here is the preliminary proposal, if

Re: [swift-evolution] Pitch: Member lookup on String should not find members of NSString

I would feel better about it if String gained a lot of the utility of NSString (so that we don’t have to go to NSString all the time for methods) Thanks, Jon > On Oct 24, 2017, at 3:00 PM, Slava Pestov via swift-evolution > wrote: > > Hi, > > Members of NSString, except those defined in Foun

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

Also of interest to this discussion is the following from a discussion on C#’s version of Set: > HashSet is more or less modeled after a mathematical set > , which means that: > > It may contain no duplicate values. > Its elements are in no partic

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

> On Oct 17, 2017, at 11:46 AM, Xiaodi Wu wrote: > > > On Tue, Oct 17, 2017 at 12:54 Jonathan Hull > wrote: >> On Oct 17, 2017, at 9:34 AM, Xiaodi Wu > > wrote: >> >> >> On Tue, Oct 17, 2017 at 09:42 Jonathan Hull > >

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

> On Oct 17, 2017, at 11:47 AM, Michael Ilseman via swift-evolution > wrote: > > `==` conveys substitutability of the two Sequences. This does not necessarily > entail anything about their elements, how those elements are ordered, etc., > it just means two Sequences are substitutable. `elemen

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

> On Oct 17, 2017, at 9:34 AM, Xiaodi Wu wrote: > > > On Tue, Oct 17, 2017 at 09:42 Jonathan Hull > wrote: >> On Oct 17, 2017, at 5:44 AM, Xiaodi Wu > > wrote: >> >> >> On Tue, Oct 17, 2017 at 00:56 Thorsten Seitz >

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

> On Oct 17, 2017, at 5:44 AM, Xiaodi Wu wrote: > > > On Tue, Oct 17, 2017 at 00:56 Thorsten Seitz > wrote: > > > Am 17.10.2017 um 00:13 schrieb Xiaodi Wu >: > >> >> On Mon, Oct 16, 2017 at 14:21 Thorsten Seitz >

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

> On Oct 17, 2017, at 12:04 AM, Gwendal Roué via swift-evolution > wrote: > >>> Modeling is, by definition, imperfect. The question is, what imperfect >>> model is most useful _to Swift_. The idea is that conforming Set and >>> Dictionary to Collection is on balance more useful than not doing

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

, but the result has still changed because we are building on top of undefined behavior. Collection says nothing about the ordering over different builds of a program. Thanks, Jon > On Oct 16, 2017, at 4:11 PM, Jonathan Hull via swift-evolution > wrote: > >> >> On Oct

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

> On Oct 16, 2017, at 1:05 PM, Xiaodi Wu wrote: > > > On Mon, Oct 16, 2017 at 10:49 Jonathan Hull > wrote: > >> On Oct 16, 2017, at 7:20 AM, Xiaodi Wu > > wrote: >> >> To start with, the one you gave as an example at the beginning of this >

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

> On Oct 16, 2017, at 7:20 AM, Xiaodi Wu wrote: > > To start with, the one you gave as an example at the beginning of this > discussion: Two sets with identical elements which have different internal > storage and thus give different orderings as sequences. You yourself have > argued that th

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

> On Oct 15, 2017, at 9:58 PM, Xiaodi Wu wrote: > > On Sun, Oct 15, 2017 at 8:51 PM, Jonathan Hull > wrote: > >> On Oct 14, 2017, at 10:48 PM, Xiaodi Wu > > wrote: That ordering can be arbitrary, but it shouldn’t leak internal repr

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

Ok, just to summarize our options so far (in order of effort & theoretical effectiveness): 1) Do nothing - This is the easiest thing to do, but it won’t fix any problems 2) Rename the elementsEqual method: (Again, fairly easy to do, and will hopefully reduce confusion, but doesn’t fix the under

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

> On Oct 14, 2017, at 10:48 PM, Xiaodi Wu wrote: >>> That ordering can be arbitrary, but it shouldn’t leak internal >>> representation such that the method used to create identical things affects >>> the outcome of generic methods because of differences in internal >>> representation. >>> >>

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

> On Oct 15, 2017, at 3:41 PM, Xiaodi Wu via swift-evolution > wrote: > > I’ll have to mull this over to see if I can come up with a coherent and > (more) specific requirement for what makes an Iterable a Sequence, since > clearly “documented” isn’t enough. Perhaps something along the lines

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

> On Oct 14, 2017, at 9:59 PM, Xiaodi Wu wrote: > > On Sat, Oct 14, 2017 at 11:48 PM, Jonathan Hull > wrote: > >> On Oct 14, 2017, at 9:21 PM, Xiaodi Wu > > wrote: >> >> On Sat, Oct 14, 2017 at 10:55 PM, Jonathan Hull >

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

> On Oct 14, 2017, at 9:21 PM, Xiaodi Wu wrote: > > On Sat, Oct 14, 2017 at 10:55 PM, Jonathan Hull > wrote: > >> On Oct 14, 2017, at 7:55 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> > Ordered, yes, but it’s only admittedly poor

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

Because the mathematical term you talk about has conditions which must be met to be used/valid. Namely: 1) The “Alphabet” of elements must be totally ordered 2) The lexicographical comparison must be applied to ordered sequences of elements from that alphabet Neither of those conditions are me

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

> On Oct 14, 2017, at 7:55 PM, Xiaodi Wu via swift-evolution > wrote: > > > Ordered, yes, but it’s only admittedly poor wording that suggests > > multi-pass, and I don’t think anything there suggests finite. > > If a Sequence is "guaranteed to iterate the same every time," then surely it > m

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

It has been a while, but I believe a lexicographical ordering is basically a mapping from a set to the natural numbers (which should, in effect, provide a total ordering). The mapping itself can be arbitrary, but the same set of things should never map to two different sequences (which just hap

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

I would also expect lexicographicallyEquals to sort the elements (or otherwise create/reference a total ordering) before checking for equality. I would be more surprised by the behavior of a function named this than elementsEqual. Given the name, I would expect elementsEqual to return true if t

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

I like the earlier version we were talking about with both .random(in: ClosedRange<>) and .random(in:ClosedRange<>, using: RandomSource) Thanks, Jon > On Oct 12, 2017, at 10:30 PM, Brent Royal-Gordon via swift-evolution > wrote: > > On Oct 11, 2017, at 10:02 AM, Kevin Nattinger via swift-evol

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

What about the opposite then, where we internally switch to a slightly less random source, but keep the extra function so conscientious programmers can check/handle cases where there isn’t enough entropy specially if needed? Thanks, Jon > On Oct 4, 2017, at 2:55 AM, Xiaodi Wu wrote: > > Seem

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

@Xiaodi: What do you think of the possibility of trapping in cases of low entropy, and adding an additional global function that checks for entropy so that conscientious programmers can avoid the trap and provide an alternative (or error message)? Thanks, Jon > On Oct 4, 2017, at 2:41 AM, Xia

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

I like the idea of splitting it into 2 separate “Random” proposals. The first would have Xiaodi’s built-in CSPRNG which only has the interface: On FixedWidthInteger: static func random()throws -> Self static func random(in range: ClosedRange)throws -> Self On Double: stat

[swift-evolution] Get a list of Concrete Implementers for Protocols

Hi Evolution, We talked a while back about being able to get a list of all concrete implementations for a protocol (i.e. all the types that adhere to it). Is this still being planned? There are a couple of big use-cases for this: • The first is for plug-ins and other things that require regis

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

Understood. Thanks, Jon > On Oct 1, 2017, at 4:20 PM, Chris Lattner wrote: > > Something like that is possible, but makes the language/compiler more > complicated by introducing a whole new concept to the source distribution. > It also doesn’t address the cases where you want to do a parse b

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

Gotcha. What if the definitions were in a special file similar to the info.plist that was read before other parsing, with one file per package? Thanks, Jon > On Oct 1, 2017, at 4:09 PM, Chris Lattner wrote: > > On Sep 30, 2017, at 7:10 PM, Jonathan Hull wrote: >> I have a technical question

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

It won’t compile. > On Sep 30, 2017, at 7:14 PM, Taylor Swift wrote: > > what happens if two public operator declarations conflict? > > On Sat, Sep 30, 2017 at 9:10 PM, Jonathan Hull via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > I have a

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

I have a technical question on this: Instead of parsing these into identifiers & operators, would it be possible to parse these into 3 categories: Identifiers, Operators, and Ambiguous? The ambiguous category would be disallowed for the moment, as you say. But since they are rarely used, maybe

Re: [swift-evolution] Idea: Public Access Modifier Respected in Type Definition

ust saying that there is an entire body of scientific research we can use to effectively accomplish this goal (and avoid known pitfalls)… we don’t have to reinvent the wheel. Thanks, Jon > On Sep 28, 2017, at 5:31 PM, Jonathan Hull via swift-evolution > wrote: > > +1000 > &g

Re: [swift-evolution] Idea: Public Access Modifier Respected in Type Definition

+1000 This is the way it always should have worked… and it is the way my brain still expects it to work. All of the extraneous “Public”s clutter the code and make it much more difficult to read. Without it, the relatively few properties marked Internal or Private stand out. I know there is t

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

> On Sep 26, 2017, at 7:31 AM, Xiaodi Wu wrote: > > Felix and Jonathan make some good points. Some general comments: > > * I think, in general, this area needs a detailed review by those who are > expert in the domain; especially if we are to assert that the design is > cryptographically secu

Re: [swift-evolution] Re-pitch: remove(where:)

Er… sorry, by “returns results” I mean, return the removed items. Thanks, Jon > On Sep 26, 2017, at 4:59 PM, Jonathan Hull wrote: > > The main issue here is that the proposal is missing the variant which returns > the elements that are removed… and that throws out a lot of very useful use > c

Re: [swift-evolution] Re-pitch: remove(where:)

The main issue here is that the proposal is missing the variant which returns the elements that are removed… and that throws out a lot of very useful use cases. > 1. Is it right to assert that with a “removing” operation, the closure should > return `true` for removal? Yes > 2. Is it likely th

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

Instead of “UnsafeRandomSource”, I would call it “ReproducibleRandomSource”. I have also found that you often need to be able to “rewind” a reproducible random source for graphics applications: protocol ReproducibleRandomSource : RandomSource { init(seed: UInt64)

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

Alwyn just pointed out another use-case as well. If there is either a @discardableResult or two variants (one which returns a result) where the method returns the items being removed (which is to be expected of a method named “remove”), then it becomes useful in ways which filter alone is not.

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

> On Sep 26, 2017, at 2:37 AM, Alwyn Concessao wrote: > > @Jonathan Hull - You've mentioned about splitting a list using a filter > which returns the filtered list and the remainder.Is it similar to having a > filter function which does the filtering on the original collection and also > ret

Re: [swift-evolution] Additional methods for removing elements from a collection in Swift

As he says, it is an in-place equivalent of filter, so the use-cases would be similar. I could see this being extremely useful. Off the top of my head: views.remove(where: {$0.isHidden}) //Remove all views which are hidden from the list. Another thing which seems to be missing (althou

Re: [swift-evolution] (core library) modern URL types

Looks like the author posted a free copy of the paper here: http://www.hirschfeld.org/writings/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf Thanks, Jon > On Sep 20, 2017, at 10:03 PM, Thorsten Seitz via swift-evolution > wrote: > > > Am

Re: [swift-evolution] Enums and Source Compatibility

Ah, ok. I had missed this too, somehow. > On Sep 17, 2017, at 4:04 PM, BJ Homer via swift-evolution > wrote: > > Please note that, as proposed, enums are always treated as exhaustive *within > the same module*. A new user writing MyFirstEnum is likely using it within > the same module, and w

  1   2   3   4   5   >