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

; >> On Dec 19, 2017, at 3:31 PM, Kevin Ballard via swift-evolution >> wrote: >> >> So I guess I’m saying, I want more thought put on the topic of whether enums >> defined in Swift should actually default to non-exhaustive, and I’m now >> leaning towards the

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

> On Dec 19, 2017, at 2:58 PM, Ted Kremenek wrote: > https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md > > > What is your evaluation of the proposal? > Overa

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

On Wed, Nov 15, 2017, at 12:55 PM, John McCall via swift-evolution wrote:> Hello, Swift Community! > > The initial review of "SE-0187: Introduce Sequence.filterMap(_:)" > ran through yesterday, November 14th, 2017. The proposal is > available here:> >> https://github.com/apple/swift-evolution/b

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

On Wed, Nov 8, 2017, at 09:29 PM, Paul Cantrell via swift-evolution wrote:> The problem in the Doodads example is that *the name flatMap is used > to identify two distinct intents*: concatenating arrays and filtering > nils. One can argue that those two operations are, in some lofty > abstract sen

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

On Wed, Nov 8, 2017, at 02:29 PM, Max Moiseev via swift-evolution wrote:> > >> On Nov 8, 2017, at 12:20 PM, Tino Heth <2...@gmx.de> wrote: >> >> >>> This is a wonderful example! But it’s an argument for a different >>> discussion (of general usefulness of implicit optional promotion). >>> Thank

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

On Wed, Nov 8, 2017, at 11:28 AM, Max Moiseev wrote: > > >> On Nov 7, 2017, at 3:34 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:>> >> On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift- >> evolution wrote:>>>> >>

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

On Tue, Nov 7, 2017, at 05:23 PM, Tino Heth via swift-evolution wrote: > -1 > > I guess breaking existing code will be the show stopper for this > proposal — but I generally think that compatibility is a poor > rationale to stop an improvement, so my personal reasons are > different:> The name is

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

On Tue, Nov 7, 2017, at 09:37 PM, John McCall wrote: > >> On Nov 7, 2017, at 6:34 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote:>> >> On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift- >> evolution wrote:>>>> >> h

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

On Tue, Nov 7, 2017, at 03:23 PM, John McCall via swift-evolution wrote:>> https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md> > • What is your evaluation of the proposal? This proposal is going to cause an insane amount of code churn. The proposal sugges

Re: [swift-evolution] [Announcement] Godbolt Compiler Explorer adds Swift support

er and whether or not > to enable optimisations, so you can see the effect of the options on > the generated code. In addition, it prints out the command that is run > at the bottom so you can do the same yourself outside of the GUI.> > Alex > >> On 23 Jun 2017, at 02:58, Kevin

Re: [swift-evolution] [Announcement] Godbolt Compiler Explorer adds Swift support

That's pretty cool. Any plans on adding support for looking at the SIL output? -Kevin Ballard On Thu, Jun 22, 2017, at 10:24 AM, Adam Nemecek via swift-evolution wrote:> Howdy, > Matt Godbolt and I have added Swift support to his compiler > explorer project> > https://swift.godbolt.org/ > > I

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

> 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 about having this kind of vague `encodedOffset` that ha

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

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 > > that compare unequal but actually return the same value when used in a > > subscript. > > For

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

https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md Overall it looks pretty good. But unfortunately the answer to "Will applications still compile but produce

Re: [swift-evolution] [swift-evolution-announce] [swift-build-dev] [Review] SE-0175 Package Manager Revised Dependency Resolution

On Tue, May 2, 2017, at 07:22 PM, Rick Ballard wrote: > Proposal link: > https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md > * What is your evaluation of the proposal? Big +1. This makes the package manager behave much more like h

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0164: Remove final support in protocol extensions

On Wed, Apr 5, 2017, at 03:05 PM, Douglas Gregor wrote: > * What is your evaluation of the proposal? It sounds like the keyword doesn't do anything right now, so +1. -Kevin Ballard ___ swift-evolution mailing list swift-evolution@swift.org https://l

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Wed, Mar 22, 2017, at 01:58 PM, Kevin Ballard wrote: > On Mon, Mar 20, 2017, at 04:54 PM, Douglas Gregor wrote: >> * What is your evaluation of the proposal? > > Huge -1, and I agree strongly with Drew Crockford's emails on > this topic. My apologies, Drew. It's Drew Crawford. -Kevin Ba

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

On Mon, Mar 20, 2017, at 04:54 PM, Douglas Gregor wrote: > * What is your evaluation of the proposal? Huge -1, and I agree strongly with Drew Crockford's emails on this topic. -Kevin Ballard ___ swift-evolution mailing list swift-evolution@swift.org

Re: [swift-evolution] Replace named returns with `out` parameters?

I know you've already decided against this, but I think it deserves an explanation for why the two are different. Tuples in function parameters was basically a special case to the type system. The function type was effectively modeled as taking one argument which was a tuple, and a function of mu

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

On Fri, Dec 16, 2016, at 06:30 AM, Charles Srstka wrote: >> On Dec 16, 2016, at 12:36 AM, Kevin Ballard wrote: >> >> On Thu, Dec 15, 2016, at 03:01 PM, Charles Srstka wrote: On Dec 15, 2016, at 4:33 PM, Kevin Ballard wrote: The problem with that code isn't that `dynamic` doesn'

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

On Thu, Dec 15, 2016, at 03:01 PM, Charles Srstka wrote: >> On Dec 15, 2016, at 4:33 PM, Kevin Ballard wrote: >> >> The problem with that code isn't that `dynamic` doesn't work for >> computed properties. It does; if you mutate the `foo` property, >> you'll get the KVO notifications. The problem

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

On Thu, Dec 15, 2016, at 02:33 PM, Kevin Ballard wrote: > On Thu, Dec 15, 2016, at 02:29 PM, Charles Srstka wrote: > > > On Dec 15, 2016, at 2:51 PM, Michael Ilseman via swift-evolution > > > wrote: > > > > > >> I don't think we should ever make it possible to mark an entire class as > > >> `dy

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

On Thu, Dec 15, 2016, at 02:29 PM, Charles Srstka wrote: > > On Dec 15, 2016, at 2:51 PM, Michael Ilseman via swift-evolution > > wrote: > > > >> I don't think we should ever make it possible to mark an entire class as > >> `dynamic`. This just reintroduces the Obj-C problem, where many propert

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

On Thu, Dec 15, 2016, at 12:51 PM, Michael Ilseman wrote: > >> On Dec 14, 2016, at 6:32 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> I don't think we should ever make it possible to mark an entire class >> as `dynamic`. Th

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

On Wed, Dec 14, 2016, at 05:54 PM, Brian King wrote: > > Please no. Just because I have to subclass NSObject doesn't mean I want to > > discard the performance benefits of static dispatch, and it especially > > doesn't mean I want to actually change the semantics of method resolution. > > Taking

Re: [swift-evolution] [Pitch] Changing NSObject dispatch behavior

Please no. Just because I have to subclass NSObject doesn't mean I want to discard the performance benefits of static dispatch, and it especially doesn't mean I want to actually change the semantics of method resolution. Taking an existing Swift class and changing its base class to NSObject shou

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

On Fri, Dec 9, 2016, at 11:50 AM, Dave Abrahams via swift-evolution wrote: > > on Fri Dec 09 2016, Andrew Trick wrote: > > >> On Dec 9, 2016, at 10:27 AM, Dave Abrahams via swift-evolution > > wrote: > >> > >> > >> on Thu Dec 08 2016, Xiaodi Wu >> > wrote: > >

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

This sounds like a sensible idea. But there is one behavioral change you haven't addressed, which is that this changes how indexes work on the slice. With all other slice types that come to mind, the slice shares the same indexes as the base, e.g. let ary = Array(0..<10) print(ary[3]) // pri

Re: [swift-evolution] private & fileprivate

On Fri, Oct 14, 2016, at 02:54 PM, Nevin Brackett-Rozinsky via swift-evolution wrote: > On Fri, Oct 14, 2016 at 11:51 AM, Daniel Duan wrote: >> >> >> On Oct 13, 2016, at 9:03 PM, Nevin Brackett-Rozinsky >> wrote: >>> Daniel, I would be interested to hear what, exactly, are the >>> benefits your

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

I'm actually vaguely surprised that the other currency symbols are considered valid identifiers, since they're not alphanumeric symbols. As for turning them into operators, it's a cute idea, but it doesn't work for any symbol that's used by multiple countries. For example, would $3.50 be USD, AUD,

Re: [swift-evolution] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

On Mon, Oct 17, 2016, at 11:25 PM, Jean-Denis Muys via swift-evolution wrote: > Now for the elephant in the room: '$' is a currency symbol. As such it > should be handled like any other currency symbol. Thinking otherwise > would be very culturally offensive. > > So can I use € as an variable name

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0144: Allow Single Dollar Sign as a Valid Identifier

On Fri, Oct 14, 2016, at 12:59 PM, Chris Lattner wrote: > * What is your evaluation of the proposal? -1. I agree with the reasons for removal, and do not consider the existence of a single library that depends on undocumented behavior to be sufficient reason for this change. > * How

Re: [swift-evolution] private & fileprivate

On Sat, Oct 8, 2016, at 07:42 AM, Anton Zhilin via swift-evolution wrote: > As far as I can see, almost all people, who talk here, agree that > private / fileprivate distinction brought more harm than good. Despite > corresponding proposal being accepted. > I think, it means that current mailing-li

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

On Tue, Oct 4, 2016, at 12:01 PM, Xiaodi Wu wrote: > On Tue, Oct 4, 2016 at 1:49 PM, Kevin Ballard wrote: >> __ >> On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote: >>> On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution >>> wrote: >>>&g

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

On Tue, Oct 4, 2016, at 11:34 AM, Xiaodi Wu wrote: > On Tue, Oct 4, 2016 at 1:06 PM, Kevin Ballard via swift-evolution evolut...@swift.org> wrote: >> __ >> >> On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote: >>> >>>> On Oct 4, 2016, at 10:29 AM,

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

On Tue, Oct 4, 2016, at 10:44 AM, Mark Lacey wrote: > >> On Oct 4, 2016, at 10:29 AM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote: >>>> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via

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

On Tue, Oct 4, 2016, at 10:28 AM, Nate Cook wrote: >> On Oct 3, 2016, at 5:49 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote: >>>> >>>> ... >>>> >>&

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

On Mon, Oct 3, 2016, at 06:49 PM, Robert Widmann wrote: > >> On Oct 3, 2016, at 8:49 PM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> I assume you meant that as a reply to me? >> >> The problem is twofold: >> >> 1. Printin

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

On Mon, Oct 3, 2016, at 02:51 PM, Dave Abrahams via swift-evolution wrote: > > on Mon Oct 03 2016, Kevin Ballard wrote: > > > On Fri, Sep 30, 2016, at 08:53 PM, Dave Abrahams via swift-evolution wrote: > >> > >> on Wed Sep 28 2016, Erica Sadun wrote: > >> > >> > Indices have a specific, fixed

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

I assume you meant that as a reply to me? The problem is twofold: 1. Printing the value without adornment, or "nil" for nil, is a very common thing to want to do and we shouldn't have to write code like `\(x.map(String.init(describing:)) ?? "nil")` to accomplish it. 2. Due to the changes ma

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

On Mon, Oct 3, 2016, at 03:18 PM, Jordan Rose wrote: > >> On Oct 3, 2016, at 14:41, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> On Mon, Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift- >> evolution wrote: >>> Swift developer

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

On Mon, Oct 3, 2016, at 10:52 AM, Harlan Haskins via swift-evolution wrote: > Swift developers frequently use string interpolation as a convenient, > concise syntax for interweaving variable values with strings. The > interpolation machinery, however, has surprising behavior in one > specific case:

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

On Fri, Sep 30, 2016, at 08:53 PM, Dave Abrahams via swift-evolution wrote: > > on Wed Sep 28 2016, Erica Sadun wrote: > > > Indices have a specific, fixed meaning in Swift, which are used to create > > valid collection > > subscripts. This proposal introduces indexed() to produce a more > > s

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

Well you kind of did say it should be removed. If we came up with a new design that produced an Int for sequences and an Index for collections, then you can't get an Int for collections (without wrapping the collection in AnySequence), which is basically the same thing as just removing enumerated()

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

There's more uses for enumerated() than just producing Array indices. -Kevin On Wed, Sep 28, 2016, at 05:49 PM, Colin Barrett via swift-evolution wrote: > Definitely well motivated. It seems like having both .enumerated() and > .indexed() methods would still leave open the possibility of novices

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

On Wed, Sep 28, 2016, at 02:27 PM, plx via swift-evolution wrote: > +1 to have something *like* this, but a few questions. > > Is there a specific reason `IndexedSequence` isn’t > `IndexedCollection`, conforming to `Collection` (and once conditional > conformances are available picking up `Bidirect

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

On Wed, Sep 28, 2016, at 02:10 PM, Tim Vermeulen wrote: > >> On 28 Sep 2016, at 23:03, Kevin Ballard wrote: >> >> On Wed, Sep 28, 2016, at 02:02 PM, Tim Vermeulen wrote: >>> On 28 Sep 2016, at 22:57, Kevin Ballard wrote: On Wed, Sep 28, 2016, at 01:54 PM, Tim Vermeulen wrote: >

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

On Wed, Sep 28, 2016, at 02:02 PM, Tim Vermeulen wrote: > > > On 28 Sep 2016, at 22:57, Kevin Ballard wrote: > > > > On Wed, Sep 28, 2016, at 01:54 PM, Tim Vermeulen wrote: > >> > >>> On 28 Sep 2016, at 22:46, Kevin Ballard wrote: > >>> > >>> That's a bunch of complexity for no benefit. Why w

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

On Wed, Sep 28, 2016, at 01:54 PM, Tim Vermeulen wrote: > > > On 28 Sep 2016, at 22:46, Kevin Ballard wrote: > > > > That's a bunch of complexity for no benefit. Why would you ever use this as > > a collection? > > I think there is a benefit. Something like `collection.indexed().reversed()` >

Re: [swift-evolution] [Proposal draft] Introducing `indexed()` collections

That's a bunch of complexity for no benefit. Why would you ever use this as a collection? The whole point is to be used in a for loop. If it was a collection then you'd need to have an index for that collection, so now you have an index that lets you get the index for another collection, which i

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

On Fri, Sep 23, 2016, at 04:50 PM, Douglas Gregor wrote: > * What is your evaluation of the proposal? +1. This looks like a great addition. I'm not fond of the shorthand syntax in the Alternatives section though > * Is the problem being addressed significant enough to warrant a >change to

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

On Sun, Aug 28, 2016, at 01:28 PM, Dave Abrahams via swift-evolution wrote: > > on Fri Aug 26 2016, Kevin Ballard wrote: > > > Goddammit. I completely missed this thread, because Pipermail > > regularly decides not to deliver the swift-evolution-announce version > > of review threads (which mean

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

t?.httpVersion < HTTPVersion(1,0) { -Kevin > Patrick > > > On 28 Aug 2016, at 1:20 PM, Kevin Ballard via swift-evolution > > wrote: > > > > As for optional comparisons making the code cleaner, I end up using them > > all over the place. The case

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

t; }) >> >> Which aside from being a brain teaser how to properly maintain >> ordering when $0.0's lastName != nil && $0.1's lastName == nil, adds >> additional few lines. >> >> But I agree that it may come as confusing with Ints, etc. - with >&g

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

I find it useful because Optionals show up all over the place, and it’s very convenient to be able to compare Optional values in a straightforward fashion. Especially when you have two Optional values to compare (as opposed to comparing an Optional with a non-Optional). `nil < .some(x)` evaluati

Re: [swift-evolution] [Accepted] SE-0121: Remove Optional Comparison Operators

Goddammit. I completely missed this thread, because Pipermail regularly decides not to deliver the swift-evolution-announce version of review threads (which means they bypass my inbox). Why does it do this? Most of the emails get delivered, but it just skips some of them, and I keep ending up mi

Re: [swift-evolution] Passing an optional first argument to sequence(first:next:)

AFAIK this issue has never been discussed with sequence(first:next:) before. It certainly wasn't brought up during review. As for my opinion, I'm really not sure. I was going to point out that right now sequence(first:next:) guarantees that the first element of the resulting sequence is the value

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0137: Avoiding Lock-In to Legacy Protocol Designs

On Wed, Aug 10, 2016, at 02:03 PM, John McCall wrote: > * What is your evaluation of the proposal? +1 > * Is the problem being addressed significant enough to warrant a >change to Swift? Yes. > * Does this proposal fit well with the feel and direction of Swift? Yes. > * If you have us

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

e accepted that they do not need to >>> enter every segment of computing so the extra performance they could >>> get on some devices is not worth the risk and the complexity it >>> brings. Not everyone is trying to cram complex 3D experiences at 60- >>> 90+

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

xtra performance they could > get on some devices is not worth the risk and the complexity it > brings. Not everyone is trying to cram complex 3D experiences at 60- > 90+ FPS on a console like constrained devices and I guess Rust is not > targeting that right now :). > > On Thu, Aug

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

For anyone interested in reading more about Rust's decisions, here's two links: The email about abandoning segmented stacks: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html The RFC to remove green threading, with motivation: https://github.com/aturon/rfcs/blob/remove-runti

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

The Rust language used to use a green thread model like Go (actually it exposed a configurable threading interface so you could choose green threads or OS threads). It also used segmented stacks like Go did. Over time, Rust ended up dropping the segmented stacks because it significantly complica

Re: [swift-evolution] [Review] SE-0136: Memory Layout of Values

On Sun, Aug 7, 2016, at 11:18 AM, Dave Abrahams via swift-evolution wrote: > * What is your evaluation of the proposal? +1 > * Is the problem being addressed significant enough to warrant a > change to Swift? Yes. > * Does this proposal fit well with the feel and dir

Re: [swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

The documentation is wrong (for Swift). For file URLs, this method returns true/false without throwing an error (at least, if the file doesn't exist there's no error; I don't know if there are conditions that would cause an error to be returned). For non-file URLs this method throws an error. Th

Re: [swift-evolution] Why does URL.checkResourceIsReachable() return a Bool?

Well that's curious. I tested in the REPL for URL(fileURLWithPath: "/foo/bar") and it simply returned false, but running the script does throw an error. And doubly-weird, if I go back to the REPL and prefix the call with `try?` the value becomes nil instead of false. So that's pretty confusing. It

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

t; >>> >>>> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution >>>> mailto:swift-evolution@swift.org>> wrote: >>>> >>>>> >>>>> On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evolution >>>>&

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

> On Aug 5, 2016, at 5:16 PM, Erica Sadun wrote: > > >> On Aug 5, 2016, at 4:19 PM, Douglas Gregor via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Aug 5, 2016, at 12:59 PM, Kevin Ballard via swift-evol

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

If all you want to do is get the localized description, then you can just say `(error as NSError).localizedDescription`. -Kevin On Fri, Aug 5, 2016, at 02:59 AM, Jean-Daniel Dupas wrote: > >> Le 5 août 2016 à 05:12, Kevin Ballard via swift-evolution > evolut...@swift.org> a écr

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

With NSError, you *must* check the domain before trying to interpret the code, or else your code is buggy and will behave incorrectly when receiving an unexpected error. With SE-0112, instead of checking the domain, you check if the Error can be casted to the particular error type that represents t

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

On Wed, Aug 3, 2016, at 11:06 AM, Felipe Cypriano via swift-evolution wrote: > On Wed, Aug 3, 2016, at 03:01, Brent Royal-Gordon via swift- > evolution wrote: 3. Native on every platform. >>> Browsers too. >> >> Safari is native, but Discourse in Safari is not by any means >> native. Any >> at

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

You're assuming that every error passed to that method is a CKError. The documentation does not claim that to be true, so it's quite plausible that you might get other errors that are simply passed through. -Kevin On Tue, Aug 2, 2016, at 02:19 PM, Jon Shier via swift-evolution wrote: > Thanks Dou

Re: [swift-evolution] [Accepted] SE-0112: Improved NSError Bridging

It did not eliminate that ability at all. You just need to say `Swift.Error` instead of `Error` when referring to the protocol if a nested `Error` type is in scope. For example: class MyClass { enum Error: Swift.Error { case somethingWentWrong } } -Kevin Ballard On Tue, Aug 2, 20

Re: [swift-evolution] [Swift4] Mailing list vs. Forum

I don't understand the suggestions for Slack. That would be a wildly inappropriate medium for long-form discussions that need to be visible to the wider community. Slack is a real-time chat platform, appropriate for immediate discussions between a small set of people. So, for example, you might

Re: [swift-evolution] [Discussion] Breaking precedence

Not a bug. `(1 as Int/3) as Double` is a type error, because you can't cast Int to Double that way, so in order to resolve the types in this expression the 1 and 3 end up inferred as Doubles as that's the only way to make the output compatible with `as Double`. In other words, with this example, t

Re: [swift-evolution] [META] Gmane and Swift Evolution

On Sun, Jul 31, 2016, at 03:42 PM, Chris Lattner via swift-evolution wrote: > >> On Jul 31, 2016, at 3:40 PM, Erica Sadun via swift-evolution > evolut...@swift.org> wrote: >> >> Gmane.org[1] is shutting down. >> http://ostatic.com/blog/mint-18-xfce-imminent-gmane-org-shutting-down >> writes: >> >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

On Tue, Jul 5, 2016, at 04:11 PM, Chris Lattner wrote: > * What is your evaluation of the proposal? Mixed bag. I'm a big fan of sealed-by-default for classes. But I want a keyword (e.g. `sealed`) for this so I can be explicit about it too. Just as I sometimes mark methods as `internal` to

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0118: Closure Parameter Names and Labels

On Tue, Jul 5, 2016, at 04:10 PM, Chris Lattner wrote: > * What is your evaluation of the proposal? Strong +1. Overall I like all of the changes listed in this proposal, with some commentary below. > lines.split(whereSeparator: isAllWhitespace) I think this is ok, but I'd also be fine wit

Re: [swift-evolution] [Review] SE-0105: Removing Where Clauses from For-In Loops

On Fri, Jun 24, 2016, at 11:03 AM, Erica Sadun via swift-evolution wrote: > > > On Jun 24, 2016, at 11:26 AM, Karl Wagner via swift-evolution > > wrote: > > > > -1 > > > > I've followed this discussion since the beginning, and I feel the usage is > > clear given that for...in is a *data-drive

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0105: Removing Where Clauses from For-In Loops

> * What is your evaluation of the proposal? -1. I don't think this is really a big deal, but I find where clauses on for loops to be very elegant, and I'm not convinced by any of the arguments for why they should go away. I'm especially not convinced by the argument over the behavior its

Re: [swift-evolution] [Review #2] SE-0089: Renaming String.init(_: T)

On Sat, Jun 4, 2016, at 11:24 AM, Chris Lattner via swift-evolution wrote: > * What is your evaluation of the proposal? +1 in general, but I still think String.init(describing:) is annoyingly long and would prefer String.init(from:). Also, I'm a little concerned by this bit: > As a perfor

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

> > > > > > On 26 May 2016, at 1:51 PM, Kevin Ballard via swift-evolution > > > wrote: > > > > > > On Wed, May 25, 2016, at 08:49 PM, Chris Lattner wrote: > > >> > > >>> On May 25, 2016, at 8:39 PM, Kevin Ballard via s

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

parameters. > > > > On 26 May 2016, at 1:51 PM, Kevin Ballard via swift-evolution > > wrote: > > > > On Wed, May 25, 2016, at 08:49 PM, Chris Lattner wrote: > >> > >>> On May 25, 2016, at 8:39 PM, Kevin Ballard via swift-evolution > >>

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

On Wed, May 25, 2016, at 08:49 PM, Chris Lattner wrote: > > > On May 25, 2016, at 8:39 PM, Kevin Ballard via swift-evolution > > wrote: > > > > On Thu, May 19, 2016, at 05:52 PM, Kevin Ballard wrote (on a different > > thread): > >> After having given

Re: [swift-evolution] [swift-evolution-announce] [Accepted with Revision] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

On Thu, May 19, 2016, at 05:52 PM, Kevin Ballard wrote (on a different thread): > After having given this some thought, it seems apparent that > `sequence(state:next:)` is equivalent to `AnyIterator({ ... })` where > the closure captures a single mutable variable. The microbenchmark > performance

Re: [swift-evolution] [Accepted with Revision] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

And I've just grabbed that bug, and will whip up an initial implementation shortly :D I'm also going to update the proposal with the name change in a minute. -Kevin Ballard On Wed, May 25, 2016, at 07:54 PM, Jacob Bandes-Storch via swift-evolution wrote: > Great news! > > I've filed a bug fo

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

On Wed, May 25, 2016, at 02:56 PM, Karl Wagner via swift-evolution wrote: > What is so bad about the global function idea? > > reflect(_:Any)->String > > It’s invoking the reflection APIs, doing a bunch of things you could do > yourself with Mirror, and returning a String. > > I know we don’t h

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

On Wed, May 25, 2016, at 01:08 PM, Dave Abrahams wrote: > > > > On behalf of Dmitri Gribenko, Max Moiseev, and myself: > > on Thu May 19 2016, Kevin Ballard > wrote: > > > After having given this some thought, it seems apparent that `sequence > > (state:next:)` is equivalent to `AnyIterator(

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol syntax with Any

On Tue, May 24, 2016, at 11:06 AM, Chris Lattner wrote: > * What is your evaluation of the proposal? +1. protocol<...> feels like a weird corner of the language that not a lot of people know about. Also, changing to Any<...> opens the door to allowing classes in the list instead of just pr

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0098: Lowercase didSet and willSet for more consistent keyword casing

On Tue, May 24, 2016, at 11:07 AM, Chris Lattner wrote: > * What is your evaluation of the proposal? -1. The only real rationale here is "other keywords that are compound words are all lowercase instead of camelCase" (except for dynamicType). But that's not a very compelling argument. More

Re: [swift-evolution] [Review] SE-0093: Adding a public base property to slices

On Mon, May 23, 2016, at 03:15 PM, Max Moiseev wrote: > Hi Kevin, > > Thanks for reviewing this proposal. > > It is my poor choice of words to be blamed for the confusion. There is > definitely no reason for the new property to only be available for the > MutableRandomAccessSlice type. Moreover

Re: [swift-evolution] [Review] SE-0093: Adding a public base property to slices

On Thu, May 19, 2016, at 04:43 PM, Dave Abrahams via swift-evolution wrote: > * What is your evaluation of the proposal? The motivation sounds reasonable, as does the solution. But it seems odd to expose a property `base` on MutableRandomAccessSlice without exposing it on any other slice t

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

On Mon, May 23, 2016, at 05:44 AM, Jeremy Pereira via swift-evolution wrote: > > > On 19 May 2016, at 23:29, Chris Lattner via swift-evolution > > wrote: > > > > > > * What is your evaluation of the proposal? > > +1 > > I think I would find myself using this in loads of places, if it was

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

On Fri, May 20, 2016, at 05:14 PM, Dave Abrahams via swift-evolution wrote: > > on Fri May 20 2016, Kevin Ballard wrote: > > > On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution wrote: > >>* What is your evaluation of the proposal? > > > > I'm a little nervous about this ch

Re: [swift-evolution] [Review] SE-0089: Renaming String.init(_: T)

On Tue, May 17, 2016, at 08:32 PM, Chris Lattner via swift-evolution wrote: > * What is your evaluation of the proposal? I'm a little nervous about this change, because converting things to strings is a fairly basic operation and it should be immediately obvious how to do that. That said,

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

016, at 10:52 AM, Kevin Ballard via swift-evolution > evolut...@swift.org> wrote: >> >> After having given this some thought, it seems apparent that >> `sequence(state:next:)` is equivalent to `AnyIterator({ ... })` >> where the closure captures a single mutable variable.

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

After having given this some thought, it seems apparent that `sequence(state:next:)` is equivalent to `AnyIterator({ ... })` where the closure captures a single mutable variable. The microbenchmark performance may differ slightly, as the AnyIterator version will allocate a box on the heap to hold

Re: [swift-evolution] [Review] SE-0094: Add sequence(initial:next:) and sequence(state:next:) to the stdlib

On Thu, May 19, 2016, at 04:20 PM, Trent Nadeau via swift-evolution wrote: > Also note that there's a typo in the second example: > > for view in sequence(initial: someView, next: { $.superview }) { // > someView, someView.superview, someView.superview.superview, ... } > > should be: > > for view

Re: [swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

pe being AnySequence? It’s > used in other areas: > > LazySequence & FlattenSequence’s > dropFirst(n: Int) -> AnySequence > dropLast(n: Int) -> AnySequence > > No need to introduce another type, and it’s straight forward to > implement with AnySequence. > >

Re: [swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

On Fri, May 13, 2016, at 11:08 AM, Erica Sadun wrote: > On May 1, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution evolut...@swift.org> wrote: >> >>> The proposal has been updated as per feedback from the core team >>> (https://github.com/apple/swift-evolution/pull/275). This includes >>>

Re: [swift-evolution] [Review] SE-0086: Drop NS Prefix in Swift Foundation

On Mon, May 9, 2016, at 03:20 PM, Douglas Gregor via swift-evolution wrote: > * What is your evaluation of the proposal? +1 to enum renaming / hoisting, including turning NSStringEncoding into an enum, but -1 on dropping the NS prefix. I agree with a lot of what the other -1 people have said, bu

  1   2   3   >