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

> On Jan 9, 2018, at 11:01 AM, Ben Cohen via swift-evolution > wrote: > > > >> On Jan 9, 2018, at 2:12 AM, Jonathan Hull via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> - Why bother supporting non-closed Ranges at all? If you only allow closed >> ranges, then you c

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

Sent from my iPhone > On Dec 21, 2017, at 2:33 PM, Ethan Diamond wrote: > > >> On Dec 21, 2017, at 10:59 AM, Dave Abrahams wrote: >> >> >> >>> On Dec 21, 2017, at 10:19 AM, Ethan Diamond wrote: >>> >>> Just to clarify, Dave - >>> >>> What happens there if one case has associated values

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

> On Dec 21, 2017, at 10:19 AM, Ethan Diamond wrote: > > Just to clarify, Dave - > > What happens there if one case has associated values > and one has an associated value thats an optional? > > Enum A { >case x(String?) >case y > } > > let a = A.x(nil) A.x is String?? > a.y // W

Re: [swift-evolution] Evaluating the case of an enum with associated values as a bool

IIRC what we discussed was synthesizing members of type Optional which could then be checked against nil. if _ = x.failure { ... } if x.failure != nil { ... } if let r = x.success {...} IMO synthesizing predicates would be a huge missed opportunity by comparison Sent from my iPhone > On Dec

Re: [swift-evolution] [swift-evolution-announce] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

> On Dec 19, 2017, at 3:42 PM, Dave Abrahams via swift-evolution > wrote: > > > >> On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I disagree. Let’s not reopen what is settled.

Re: [swift-evolution] [swift-evolution-announce] [Accepted with revisions] SE-0187 “Introduce Sequence.filterMap(_:)”

> On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution > wrote: > > I disagree. Let’s not reopen what is settled. “Compact” can be a noun just as > “map” and “filter” can; as long as there are no in-place variants, there can > be no ambiguity. > On Tue, Dec 19, 2017 at 17:11 Brent Roya

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

Sent from my iPhone > On Dec 12, 2017, at 12:29 PM, Alejandro Martinez via swift-evolution > wrote: > > Yes that's what I was suggesting. > My view is that different kind of conversations would happen in a > "help" vs. "announcements" category. Some people may be interested in > being up to d

Re: [swift-evolution] [RFC] Associated type inference

> On Nov 30, 2017, at 2:28 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > Associated type inference, which is the process by which the Swift compiler > attempts to infer typealiases to satisfy associated-type requirements based > on other requirements, has cau

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

I don’t have much to say about this other than that I think the discussion seems way too narrow, focusing on spelling rather than on functionality and composability. I consider the “generic random number library” design to be a mostly-solved problem, in the C++ standard library (http://en.cppr

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

This sort of “it compiles if it’s syntactically valid, regardless of declared constraints” thing is deliberately avoided in Swift’s generics design with good reason; it’s possible that in this instance there are no problems, but I’m skeptical. Sent from my iPhone > On Nov 25, 2017, at 1:16 PM

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

Sent from my iPhone Begin forwarded message: > From: Matthew Johnson > Date: November 24, 2017 at 3:55:34 PM PST > To: Dave Abrahams > Subject: Re: [swift-evolution] [Pre-pitch] Conditional default arguments > > You posted off-list. If that wasn’t intentional feel free to forward my > repl

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

I’m sorry, but I think we disagree on the premise. In my opinion the square brackets do exactly what we need them to do, and it’s not for the sake of anything other than consistency with the rest of the library and incidentally, reducing API complexity that I want to use them. Sent from my iPa

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

I don't think I made any arguments that could be viewed as pointing out a problem with the slice approach, unless you take as given the idea that the slice approach should mean something novel and unprecedented. I don't see the whole/part implication that you see in the two notations, even thoug

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 29, 2017, at 4:03 PM, Taylor Swift wrote: > > > > On Sep 29, 2017, at 5:56 PM, Dave Abrahams > wrote: > >> >> >>> On Sep 29, 2017, at 3:48 PM, Taylor Swift >> > wrote: >>> >>> >>> >>> On Fri, Sep 29, 2017 at 4:13 PM, And

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 29, 2017, at 3:48 PM, Taylor Swift wrote: > > > > On Fri, Sep 29, 2017 at 4:13 PM, Andrew Trick > wrote: > > >> On Sep 29, 2017, at 1:23 PM, Taylor Swift > > wrote: >> >> Instead of >> >> buf.intialize(at: i, from: source)

Re: [swift-evolution] pure functions

on Wed Aug 23 2017, Joe Groff wrote: On Aug 18, 2017, at 12:10 PM, Chris Lattner via swift-evolution wrote: Splitting this out from the concurrency thread: On Aug 18, 2017, at 6:12 AM, Matthew Johnson wrote: On Aug 17, 2017, at 11:53 PM, Chris Lattner wrote: In the manifesto

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

on Fri Aug 18 2017, Erica Sadun wrote: On Aug 17, 2017, at 9:29 PM, Taylor Swift wrote: On Thu, Aug 17, 2017 at 9:06 PM, Erica Sadun via swift-evolution > wrote: On Aug 17, 2017, at 6:56 PM, Xiaodi Wu > wrote: On Thu

Re: [swift-evolution] Pitch: Improved Swift pointers

on Wed Aug 09 2017, Xiaodi Wu wrote: On Wed, Aug 9, 2017 at 8:22 PM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: On Jul 19, 2017, at 11:21 AM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: What about `value:`? `ptr.initialize(val

Re: [swift-evolution] typed throws

on Fri Aug 25 2017, John McCall wrote: On Aug 25, 2017, at 12:18 PM, Dave Abrahams via swift-evolution wrote: on Fri Aug 18 2017, Joe Groff wrote: On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution wrote: Essentially, you give Error a tagged-pointer representation to

Re: [swift-evolution] typed throws

on Fri Aug 18 2017, Joe Groff wrote: >> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution >> wrote: >> >> Essentially, you give Error a tagged-pointer representation to allow >> payload-less errors on non-generic error types to be allocated > >> globally, and then you can (1) tell

Re: [swift-evolution] typed throws

on Thu Aug 17 2017, John McCall wrote: >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson wrote: >>> One related topic that isn’t discussed is type errors. Many third > >

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

on Mon Jul 31 2017, John McCall wrote: >> I see your point. Dynamically-sized in-place allocation is something >> that completely escaped me when I was thinking of fixed-size >> arrays. I can say with confidence that a large portion of >> private-class-copy-on-write value types would greatly ben

Re: [swift-evolution] [pitch] CopyInitializable for value-type semantics

; > private let getter: () -> Value > > private let setter: (Value) -> Void > > } > > let v = Variable(“hello”) // a `let` constant > assert(v.value == “hello") > v = “world” // setter is nonmutating, so this is ok > assert(v.value == “world") &

Re: [swift-evolution] [pitch] CopyInitializable for value-type semantics

on Wed Jul 12 2017, Gor Gyolchanyan wrote: > Hello, swift community! > > Recently I’ve come across a dilemma regarding value-type semantics > when dealing with generic types. Consider a protocol that has a > mutating in-place function and a non-mutating returning variant of > that function: > >

Re: [swift-evolution] [swift-evolution-announce] Revision review: SE-104: Protocol-oriented integers

on Fri Jul 21 2017, Xiaodi Wu wrote: > Over the last months, I started two threads to discuss revisions to > SE-0104; these received essentially no reply. Yes, I'm sorry I didn't have time to reply at the time. These proposed revisions are, effectively, part of my response to your remarks the

Re: [swift-evolution] [Pitch] BitPatternRepresentable

on Sun Jul 16 2017, Jens Persson wrote: > On Wed, Jul 12, 2017 at 12:23 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> /../ >> As ever, my first question when a new protocol is proposed is, “what >> generic algorithms rely

Re: [swift-evolution] Pitch: Improved Swift pointers

on Wed Jul 12 2017, Taylor Swift wrote: > Hi all, I’ve written up a proposal to modify the unsafe pointer API for > greater consistency, safety, and ease of use. > > ~~~ > > Swift currently offers two sets of pointer types — singular pointers such > as UnsafeMutablePointer, and vector (buffer) p

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

on Tue Jul 11 2017, Robert Bennett wrote: > Just realized that even inout functions don’t let you do > member(object) = value. The other difference is that an inout function can't be used to get a member from an immutable value, whereas a keypath/subscript/property access can. -- -Dave

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

on Tue Jul 11 2017, Robert Bennett wrote: > Er, yes, I now realize I diverged into two different keypaths-as-functions > ideas there. > > I think that the best implementation of deferred access is keypaths as > callable first-class objects, like you (Karl) said. — although I > wonder whether ca

Re: [swift-evolution] [Pitch] BitPatternRepresentable

on Tue Jul 11 2017, Jens Persson wrote: > I've found it practical/necessary to write my own BitPatternRepresentable > protocol and IMHO it feels like something that could have been added along > with the improved numeric protocols of Swift 4. > > Would it make sense to add something like the fol

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

on Sun Jul 09 2017, Brent Royal-Gordon wrote: > But however we achieve it, I think a spoonful of > syntactic sugar would help the medicine go down. Let me be clear: syntactic sugar matters. Otherwise, we'd all be programming directly in LLVM IR. It's just a question of what you have to pay to

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

on Thu Jul 06 2017, Brent Royal-Gordon wrote: >> On Jul 6, 2017, at 9:13 AM, Dave Abrahams wrote: >> >> I'm not sure what you're objecting to about this. Is it the very >> appearance of curly braces? > > I went to bed thinking that maybe I should have explained that better, > and I guess I wa

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

on Wed Jul 05 2017, Brent Royal-Gordon wrote: >> On Jul 5, 2017, at 2:23 PM, Dave Abrahams via swift-evolution >> wrote: >> >> I am not convinced this syntactic sugar is worth complicating the >> language or library for, > > For what it's worth, I thi

Re: [swift-evolution] [Pitch] KeyPath based map, flatMap, filter

on Wed Jul 05 2017, Benjamin Herzog wrote: > Hey guys, > > I would like to pitch a small convenient change to the Swift stdlib. > With KeyPaths added in SE-0161 I would like to add some convenience > calls to map, flatMap and filter in Sequences. To extract properties of > an array of objects we

Re: [swift-evolution] [pitch] Substring performance affordances

on Wed Jun 28 2017, Ben Cohen wrote: > Hi swift-evolution, > > Below is a short pitch for some performance improvements to be made to String > to accommodate > Substrings. > > As outlined in SE-0163, the more general question of implicit conversion from > Substring to String > was deferred pen

Re: [swift-evolution] [swift-evolution-announce] [Revised and review extended] SE-0180 - String Index Overhaul

Hi Karl, It was pointed out to me that I never answered this thoughtful post of yours... on Mon Jun 26 2017, Karl Wagner wrote: >> On 23. Jun 2017, at 02:59, Kevin Ballard via swift-evolution >> wrote: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-ove

Re: [swift-evolution] [swift-evolution-announce] [Revised and review extended] SE-0180 - String Index Overhaul

on Thu Jun 22 2017, Kevin Ballard wrote: >> https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md > Given the discussion in the original thread about potentially having > Strings backed by something other than utf16 code units, I'm somewhat > concerned abou

Re: [swift-evolution] [swift-evolution-announce] [Revised and review extended] SE-0180 - String Index Overhaul

on Tue Jun 27 2017, Drew Crawford wrote: > On June 26, 2017 at 5:43:42 PM, Karl Wagner via swift-evolution > (swift-evolution@swift.org) wrote: > > I would support a definition of encodedOffset that removed mention of > UTF-16 and phrased things in terms of String.Encoding and > code-units. For

Re: [swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

on Wed Jun 14 2017, Chris Lattner wrote: >> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >> wrote: >> >> Some pals and I have been kicking an idea around about introducing >> better ways to support the compiler in protocol extensions. We want > >> to eliminate some hard-to-det

Re: [swift-evolution] Followup after in-the-field feedback for SE-0170

on Wed Jun 14 2017, Philippe Hausler wrote: > After implementing the proposal > https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md > > we have gotten some initial feedback

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Wed Jun 14 2017, Xiaodi Wu wrote: > On Wed, Jun 14, 2017 at 12:01 PM, Dave Abrahams wrote: > >> >> on Wed Jun 14 2017, Xiaodi Wu wrote: >> >> > On Wed, Jun 14, 2017 at 09:26 Xiaodi Wu wrote: >> > >> >> If we leave aside for a moment the nomenclature issue where everything >> in >> >> Found

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Wed Jun 14 2017, Xiaodi Wu wrote: > On Wed, Jun 14, 2017 at 09:26 Xiaodi Wu wrote: > >> If we leave aside for a moment the nomenclature issue where everything in >> Foundation referring to a character is really referring to a Unicode >> scalar, Kevin’s example illustrates the whole problem i

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Wed Jun 14 2017, Xiaodi Wu wrote: > On Wed, Jun 14, 2017 at 11:13 AM, Dave Abrahams wrote: > >> >> on Wed Jun 14 2017, Xiaodi Wu wrote: >> >> > However, if this desire to remove failable APIs remains strong then I >> > wonder if the undiscussed second option above is worth at least some >>

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Wed Jun 14 2017, Xiaodi Wu wrote: > If we leave aside for a moment the nomenclature issue where everything in > Foundation referring to a character is really referring to a Unicode > scalar, Kevin’s example illustrates the whole problem in a nutshell, > doesn’t it? In that example, we have a

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

> On Jun 13, 2017, at 6:16 PM, Xiaodi Wu wrote: > > I’m coming to this conversation rather late, so forgive the naive question: > > Your proposal claims that current code with failable APIs is needlessly > awkward and that most code only interchanges indices that are known to > succeed. So, w

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Tue Jun 06 2017, Dave Abrahams wrote: >> Overall it looks pretty good. But unfortunately the answer to "Will >> applications still compile but produce different behavior than they >> used to?" is actually "Yes", when using APIs provided by >> Foundation. This is because Foundation is currentl

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Mon Jun 12 2017, David Waite wrote: >> On Jun 9, 2017, at 9:24 PM, Dave Abrahams via swift-evolution > wrote: >> on Fri Jun 09 2017, Kevin Ballard >> > <mailto:swift-evolution@swift.org>> >> wrote: >>> On Tue, Jun 6, 2017, at 10:57 AM, Dave Ab

Re: [swift-evolution] Pitch: Limit typealias extensions to the typealias

on Fri Jun 09 2017, Matthew Johnson wrote: >> On Jun 9, 2017, at 12:09 PM, Xiaodi Wu via swift-evolution >> wrote: >> >> On Fri, Jun 9, 2017 at 12:44 Robert Bennett via swift-evolution >> >> > >> wrote: >> Somewhat related to this, shouldn’t it be possible to

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

on Fri Jun 09 2017, Saagar Jha wrote: > It reads better and feels more natural. In my mind, it’s similar to the > difference between > > ["1", "2", "3"].flatMap { Double($0) } > > and > > ["1", "2", "3"].flatMap(Double.init) > > Saagar Jha I am not convinced this syntactic sugar is worth comp

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Fri Jun 09 2017, Kevin Ballard wrote: > On Tue, Jun 6, 2017, at 10:57 AM, Dave Abrahams via swift-evolution wrote: >> >> on Mon Jun 05 2017, Kevin Ballard wrote: >> >> > There’s also the curious case where I can have two String.Index values >> > t

Re: [swift-evolution] Int indexing into UTF16View

on Thu Jun 08 2017, David Hart wrote: > Hello, > > When working with Strings which are known to be ASCII, I tend to use > the UTF16View for the performance of random access. I would also like > to have the convenience of indexing with Int: > > let barcode = "M1X/CLEMENT EELT9QBQGVAAMSE

Re: [swift-evolution] [Pitch] UnsafePointer.advanced(to:)

It's not an offset because the result is a different type of thing than the source Sent from my moss-covered three-handled family gradunza > On Jun 6, 2017, at 1:09 PM, Hooman Mehr wrote: > > >> On Jun 6, 2017, at 12:56 PM, Dave Abrahams via swift-evolution >> wr

Re: [swift-evolution] [Pitch] UnsafePointer.advanced(to:)

on Tue Jun 06 2017, Brent Royal-Gordon wrote: >> On Jun 6, 2017, at 9:06 AM, Xiaodi Wu wrote: >> >> Why would this be an extension on UnsafePointer and not KeyPath? > > 1. I can't come up with a name as good as `advanced(to:)` that would > be attached to the key path. I use `advance(_:)` in th

Re: [swift-evolution] [Review] SE-0180: String Index Overhaul

on Mon Jun 05 2017, Kevin Ballard wrote: > https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md > > > Overall it looks pretty good. But unfortunately the answer

Re: [swift-evolution] Rekindling: "Extending declaration scope to condition for `repeat { } while ()"

> On Tue, Jun 6, 2017 at 4:05 AM, Michael Savich via swift-evolution < > swift-evolution@swift.org> wrote: > >> It recently occurred to me how nice it would be to be if we could avoid >> declaring variables outside of loops that are only used inside them. I used >> google’s site specific search (i

Re: [swift-evolution] Pitch: String Index Overhaul

on Sat Jun 03 2017, Ben Rimmington wrote: >> On 27 May 2017, at 18:40, Dave Abrahams wrote: >> >> ## Introduction >> >> Today `String` shares an `Index` type with its `CharacterView` but not >> with its `UTF8View`, `UTF16View`, or `UnicodeScalarView`. This >> proposal redefines `String.UTF8Vi

Re: [swift-evolution] Pitch: String Index Overhaul

Philippe Hausler via swift-evolution wrote: > I would presume that the index type will still be shared between String and > SubString, Yes; that's a requirement of Collection conformance. > will this mean that we will now be able to express index manipulation in > StringProtocol? Depends wh

Re: [swift-evolution] Pitch: String Index Overhaul

on Fri Jun 02 2017, Brent Royal-Gordon wrote: >> On May 27, 2017, at 10:40 AM, Dave Abrahams via swift-evolution > wrote: >> >> A property and an intializer will be added to `String.Index`, exposing >> the offset of the index in code units (currently only UTF-16) f

Re: [swift-evolution] Yet another fixed-size array spitball session

on Fri Jun 02 2017, Brent Royal-Gordon wrote: >> On May 28, 2017, at 11:37 PM, Daryle Walker via swift-evolution >> wrote: >> >> Static-Sized Arrays > > My preference would still be to build this from four separate features: > > 1. Magic tuple conformances: We already want to be able to > auto

Re: [swift-evolution] Pitch: String Index Overhaul

on Tue May 30 2017, Jordan Rose wrote: >> On May 30, 2017, at 16:13, Dave Abrahams > wrote: >> >> >> on Tue May 30 2017, Jordan Rose > > wrote: >> > On May 30, 2017, at 14:53, Dave Abrahams wrote: on Tue May 30 2017, Jordan Rose wrote:

Re: [swift-evolution] Implicit truncation

on Tue May 30 2017, Greg Parker wrote: >> On May 26, 2017, at 12:04 AM, Xiaodi Wu via swift-evolution >> wrote: >> >> I've often wondered if even just "bitPattern" might suffice, as the >> truncating or extending of it > should not be particularly surprising. > > Being explicit about bit pat

Re: [swift-evolution] Pitch: String Index Overhaul

on Tue May 30 2017, Jordan Rose wrote: >> On May 30, 2017, at 14:53, Dave Abrahams wrote: >> >> >> on Tue May 30 2017, Jordan Rose wrote: >> >>> My knee-jerk reaction is to say it's too late in Swift 4 for this kind >>> of change, but with that out of the way, I'm most concerned about what

Re: [swift-evolution] Pitch: String Index Overhaul

on Tue May 30 2017, Michael Ilseman wrote: >> On May 27, 2017, at 10:40 AM, Dave Abrahams via swift-evolution >> wrote: >> >> >> An index that does not fall on an exact boundary in a given `String` >> or `Substring` view will be “rounded down” to t

Re: [swift-evolution] Pitch: String Index Overhaul

on Tue May 30 2017, Jordan Rose wrote: > My knee-jerk reaction is to say it's too late in Swift 4 for this kind > of change, but with that out of the way, I'm most concerned about what > it means to have, say, a UTF-8 index that's not on a UTF-16 boundary. > > let str = "言" > let oneUnitIn = str

Re: [swift-evolution] Derived Equatable conformance akin to Codable

on Fri May 26 2017, Logan Shire wrote: > Given we now have precedent in the form of the derived Codable conformance > coming in Swift 4.0, > it begs the question why we don’t offer the same behavior for value types > that declare themselves to > be Equatable > and have all Equatable properties

Re: [swift-evolution] Revisiting SE-0110

on Sun May 28 2017, Gwendal Roué wrote: >> Le 27 mai 2017 à 19:43, Dave Abrahams via swift-evolution >> a écrit : >> >> >> on Thu May 25 2017, Gwendal Roué > <mailto:swift-evolution@swift.org>> > wrote: >> > >>>> F

Re: [swift-evolution] Revisiting SE-0110

on Thu May 25 2017, Gwendal Roué 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;

[swift-evolution] Pitch: String Index Overhaul

Pretty version: https://github.com/dabrahams/swift-evolution/blob/string-index-overhaul/proposals/-string-index-overhaul.md # String Index Overhaul * Proposal: [SE-](-string-index-overhaul.md) * Authors: [Dave Abrahams](https://github.com/dabrahams) * Review Manager: TBD * Sta

Re: [swift-evolution] Implicit truncation

on Fri May 26 2017, Xiaodi Wu wrote: > Ha, I have that problem too of mistyping. I've often wondered if even just > "bitPattern" might suffice, as the truncating or extending of it should not > be particularly surprising. maybe. > That said, I'm pretty convinced the current API needs time to

Re: [swift-evolution] Implicit truncation

on Tue May 23 2017, Xiaodi Wu wrote: > On Tue, May 23, 2017 at 11:47 PM, Guillaume Lessard via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> > On May 23, 2017, at 19:55, Xiaodi Wu wrote: >> > >> > On Tue, May 23, 2017 at 5:27 PM, Guillaume Lessard via swift-evolution < >> swift-

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0163 [2]: String Revision: Collection Conformance, C Interop, Transcoding

on Thu May 11 2017, Brent Royal-Gordon wrote: >> On May 11, 2017, at 2:39 PM, John McCall wrote: >> What is your evaluation of the proposal? > These changes all look like improvements to me. (But I would say that, since > I recommended a couple > of them in the original review.) > > I notice t

Re: [swift-evolution] Quick question: Constraint Aliasing

on Fri May 12 2017, David Hart wrote: >> On 12 May 2017, at 09:05, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Thu May 11 2017, David Hart wrote: >> >>> I have the impression this would be simple enough because it would only &g

Re: [swift-evolution] [Pitch] Enumerate from offset

on Sun May 07 2017, Pavol Vaskovic wrote: > (I forgot to reply-all to mailing list, sorry for double posting Ben!) > > On Thu, May 4, 2017 at 8:11 PM, Ben Cohen via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On May 4, 2017, at 10:15 AM, Jaden Geller via swift-evolution < >> sw

Re: [swift-evolution] Quick question: Constraint Aliasing

on Thu May 11 2017, David Hart wrote: > I have the impression this would be simple enough because it would only live > in the parser. But I'm > no expert. You would need some way to tell the compiler which associated type goes in the <>s. -- -Dave ___

Re: [swift-evolution] [pitch] Comparison Reform

on Mon Apr 24 2017, Xiaodi Wu wrote: > On Mon, Apr 24, 2017 at 9:06 PM, Jonathan Hull via swift-evolution < > swift-evolution@swift.org> wrote: > >> As I am thinking about it more, this means that for == and < >> >> NaN == NaN >> -0 == +0 >> +Inf < NaN >> >> Since this would break from IEEE, > >

Re: [swift-evolution] [pitch] Comparison Reform

on Sun Apr 23 2017, Xiaodi Wu wrote: > On Sun, Apr 23, 2017 at 4:32 PM, Dave Abrahams wrote: > >> >> on Sun Apr 23 2017, Xiaodi Wu wrote: >> >> > On Sun, Apr 23, 2017 at 7:54 AM, Dave Abrahams >> wrote: >> > >> >> >> >> on Sun Apr 23 2017, Xiaodi Wu wrote: >> >> >> >> > On Sat, Apr 22, 2017

Re: [swift-evolution] [pitch] Comparison Reform

on Sun Apr 23 2017, Xiaodi Wu wrote: > On Sun, Apr 23, 2017 at 7:54 AM, Dave Abrahams wrote: > >> >> on Sun Apr 23 2017, Xiaodi Wu wrote: >> >> > On Sat, Apr 22, 2017 at 11:00 PM, Dave Abrahams >> wrote: >> > >> >> >> >> >> > That is to say, I would expect the standard library to supply an >>

Re: [swift-evolution] [Idea] Generic associated types

on Sat Mar 11 2017, Karl Wagner wrote: >> On 12 Mar 2017, at 06:51, Austin Zheng > wrote: >> >> I think you want higher-kinded >> types. >> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#higher-kinded-types >>

Re: [swift-evolution] [pitch] Comparison Reform

on Sun Apr 23 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 11:00 PM, Dave Abrahams wrote: > >> >> >> > That is to say, I would expect the standard library to supply an >> >> > alternative implementation of equality for Array> >> > FloatingPoint>. >> >> >> >> And also for Dictionary? What d

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, David Waite wrote: >> On Apr 22, 2017, at 10:58 PM, Chris Lattner via swift-evolution >> wrote: >> >> I don’t think that this proposal is acceptable as written. I think >> it is really bad that abstracting a concrete algorithm would change >> its behavior so substantially

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Chris Lattner wrote: > On Apr 22, 2017, at 6:06 PM, Xiaodi Wu wrote: >> but my quick reaction to `&==` is that it would make me quite >> nervous to have `==` not bound to 754-equals as it is in essentially >> every other language. In particular, I worry about the risk of >>

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 6:37 PM, Dave Abrahams wrote: > > >> >> >> > To be clear, this proposal promises that `[0 / 0 as Double]` will be >> made >> >> > to compare unequal with itself, yes? >> >> >> >> Nope. >> >> >> >> As you know, equality of arrays is

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: > >> >> on Tue Apr 18 2017, Xiaodi Wu wrote: >> >> > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> On Apr 17, 2017, at 9:40 P

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, David Sweeris wrote: > Maybe we should make Float/Double conform to > "IEEE754Comparable"/"IEEE754Equatable" instead of > "Comparable"/"Equatable". Then it's all a moot point since floating > point types wouldn't end up in the same generic functions as other > comparable type

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 22 2017, Xiaodi Wu wrote: > On Sat, Apr 22, 2017 at 4:14 PM, Dave Abrahams wrote: > >> >> on Tue Apr 18 2017, Xiaodi Wu wrote: >> >> > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < >> > swift-evolution@swift.org> wrote: >> > >> >> >> >> On Apr 17, 2017, at 9:40 P

Re: [swift-evolution] [pitch] Comparison Reform

on Tue Apr 18 2017, Xiaodi Wu wrote: > On Tue, Apr 18, 2017 at 10:40 AM, Ben Cohen via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> >> On Apr 17, 2017, at 9:07 AM, Joe Gro

Re: [swift-evolution] [pitch] Comparison Reform

on Tue Apr 18 2017, Ben Cohen wrote: >> On Apr 17, 2017, at 9:40 PM, Chris Lattner via swift-evolution >> wrote: >> >> >>> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >>> wrote: >>> > >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution wrote: >

Re: [swift-evolution] [pitch] Comparison Reform

on Sun Apr 16 2017, Xiaodi Wu wrote: > On Sun, Apr 16, 2017 at 1:14 PM, Jonathan Hull wrote: > >> >> On Apr 16, 2017, at 10:42 AM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> The point is that, when you manipulate two real numbers, sometimes there >> is no numeric

Re: [swift-evolution] [Pitch] Adding safety to arrays

on Mon Apr 17 2017, Karl Wagner wrote: >> On 17 Apr 2017, at 18:35, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri Apr 14 2017, Karl Wagner wrote: >> > >>> Personally, the only valid use-case I can think of is when you want to

Re: [swift-evolution] [pitch] Comparison Reform

on Sun Apr 16 2017, Xiaodi Wu wrote: > On Sun, Apr 16, 2017 at 1:13 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >>> > I have an incipient idea. It begins with: >> >> > >> >> >

Re: [swift-evolution] [Pitch] Adding safety to arrays

on Fri Apr 14 2017, Karl Wagner wrote: > Personally, the only valid use-case I can think of is when you want to > initialise an Array’s elements out-of-order - i.e., you want to set a > value for myArray[2] despite myArray[0] and [1] not being > populated. In that case, it would be better to hav

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 15 2017, Xiaodi Wu wrote: > On Sat, Apr 15, 2017 at 10:32 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Sat Apr 15 2017, Xiaodi Wu wrote: >> >> > On Sat, Apr 15, 2017 at 3:12 PM, Dave Abrahams

Re: [swift-evolution] [Pitch] Adding safety to arrays

on Thu Apr 13 2017, David Sweeris wrote: >> On Apr 13, 2017, at 3:56 AM, Andrew Hart via swift-evolution > wrote: >> >> Recently I’ve been considering the lack of safety around array indexes. >> Swift is designed with > safety in mind, so this example would not compile: >> >> var myString: S

Re: [swift-evolution] SE-0171: Reduce with inout

on Fri Apr 14 2017, Matthew Johnson wrote: >> On Apr 14, 2017, at 9:05 PM, David Sweeris wrote: >> >> >>> On Apr 14, 2017, at 15:33, Matthew Johnson via swift-evolution >>> wrote: >>> >>> • What is your evaluation of the proposal? >>> >>> +0.5 because this is a half solution. I w

Re: [swift-evolution] Yet Another Access Control Pitch: Flexible Scoping

on Fri Apr 14 2017, Erica Sadun wrote: > Pull request: https://github.com/apple/swift-evolution/pull/681 > > > Under the assumption that SE-0169 is adopted, Jeffrey B and I have > been brainstorming about what a follow-on might look like. We wa

Re: [swift-evolution] [pitch] Comparison Reform

on Sat Apr 15 2017, Xiaodi Wu wrote: > On Sat, Apr 15, 2017 at 3:12 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> on Thu Apr 13 2017, Xiaodi Wu wrote: >> >> > Getting this sorted out is definitely a worthwhile

Re: [swift-evolution] [pitch] Comparison Reform

on Thu Apr 13 2017, Xiaodi Wu wrote: > Getting this sorted out is definitely a worthwhile effort. I do have > thoughts about this proposal: > > I continue to have reservations about an identical spelling (e.g. `==`) > giving two different answers with the same values of the same type, > dependin

Re: [swift-evolution] [pitch] Comparison Reform

on Thu Apr 13 2017, Jonathan Hull wrote: > I still like the ordering of floats defined in this proposal best (and > think we should use it), but I imagine that there are other types > which are almost (but not quite) comparable as well. Would there be > any utility in having a ‘PartialComparable

Re: [swift-evolution] [Manifesto] Ownership

on Mon Mar 06 2017, Karl Wagner wrote: >> On 6 Mar 2017, at 22:30, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Mon Mar 06 2017, John McCall wrote: >> > >>>> On Mar 6, 2017, at 3:46 PM, Karl Wagner >>>> wrote: &

Re: [swift-evolution] [Manifesto] Ownership

on Mon Mar 06 2017, John McCall wrote: >> On Mar 6, 2017, at 3:46 PM, Karl Wagner >> wrote: >> Thanks very much for writing this up, it’s very interesting. >> >> The one thing which I think needs improvement is the Copyable protocol. I >> think that this is > actually part of a larger proble

  1   2   3   4   5   6   7   8   9   10   >