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 >> > wrote: >> >> - Why bother supporting non-closed Ranges

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

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)

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 > <swift-evolution@swift.org> wrote: > > > >> On Dec 19, 2017, at 2:28 PM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wr

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

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

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

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

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

[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

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

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

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

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

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

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

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

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 <swift-evolution@swift.org> wrote: on Fri Aug 18 2017, Joe Groff <swift-evolution@swift.org> wrote: On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution <

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

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

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

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

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

Re: [swift-evolution] [Pitch] BitPatternRepresentable

on Sun Jul 16 2017, Jens Persson <swift-evolution@swift.org> 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,

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

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

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

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

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

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 >> <swift-evolution@swift.org> wrote: >> >> I am not convinced this syntactic sugar is worth complicating the >> language or library f

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

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

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

on Fri Jun 09 2017, Kevin Ballard <swift-evolution@swift.org> wrote: > On Tue, Jun 6, 2017, at 10:57 AM, Dave Abrahams via swift-evolution wrote: >> >> on Mon Jun 05 2017, Kevin Ballard <swift-evolution@swift.org> wrote: >> >> > There’s also the curi

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 =

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 <hoo...@mac.com> wrote: > > >> On Jun 6, 2017, at 12:56 PM, Dave Abrahams via swift

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

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.

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

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

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 >

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

on Fri Jun 02 2017, Brent Royal-Gordon <swift-evolution@swift.org> wrote: >> On May 27, 2017, at 10:40 AM, Dave Abrahams via swift-evolution > <swift-evolution@swift.org> wrote: >> >> A property and an intializer will be added to `String.Index`, exposing >>

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

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

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

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

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 >> <swift-evolution@swift.org> wrote: >> >> >> An index that does not fall on an exact boundary in a given `String` >> or `Substring`

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 =

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

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 >> <swift-evolution@swift.org> a écrit : >> >> >> on Thu May 25 2017, Gwendal Roué <swift-evolution@swift.org >> <mailto:swift-evolu

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

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

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,

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 >

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 >> <swift-evolution@swift.org> wrote: >> >> >> on Thu May 11 2017, David Hart <swift-evolution@swift.org> wrote: >> >>> I have th

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

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

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

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

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

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

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,

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

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

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

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

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

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

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

on Mon Apr 17 2017, Karl Wagner <swift-evolution@swift.org> wrote: >> On 17 Apr 2017, at 18:35, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> on Fri Apr 14 2017, Karl Wagner <swift-evolution@swift.org> wrote:

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

on Sun Apr 16 2017, Xiaodi Wu <swift-evolution@swift.org> 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

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

on Sat Apr 15 2017, Xiaodi Wu <swift-evolution@swift.org> 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 <swift-evolution@swift.org> wrote: >&g

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

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

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

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

on Sat Apr 15 2017, Xiaodi Wu <swift-evolution@swift.org> 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 <swift-evolution@swift.org> wrote: >&g

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

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

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 >> <swift-evolution@swift.org> wrote: >> >> >> on Mon Mar 06 2017, John McCall <swift-evolution@swift.org> 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

Re: [swift-evolution] 'T != Type' in where clause

on Wed Mar 01 2017, Douglas Gregor wrote: >> On Mar 1, 2017, at 1:55 AM, Jonathan Hull wrote: >> >> What I would like is a way to specialize a generic function in a block of >> code: (Strawman syntax) >> >> if T is Int.self { >>

Re: [swift-evolution] [Review] SE-0157: Support recursive constraints on associated types

on Tue Feb 28 2017, John McCall wrote: > What is your evaluation of the proposal? +1, duh -- -Dave ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Typed throws

on Tue Feb 28 2017, Karl Wagner wrote: >> On 28 Feb 2017, at 18:00, Matthew Johnson wrote: >> >> >>> On Feb 28, 2017, at 10:44 AM, Daniel Leping > wrote: >>> > >>> Mathew, I totally understand what you're

  1   2   3   4   5   6   7   8   9   10   >