Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 2:51 PM, Jean-Daniel via swift-evolution > wrote: > >> Le 19 mars 2017 à 16:41, Ricardo Parada via swift-evolution >> mailto:swift-evolution@swift.org>> a écrit : >> >> I agree that they can get mixed up with static properties. However, I think >> I would not mind becaus

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon > wrote: > >> On Mar 19, 2017, at 12:57 PM, Charles Srstka via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> I disagree. How the reader is supposed to now there is a static prop

Re: [swift-evolution] Smart KeyPaths

> On Mar 19, 2017, at 4:15 PM, Matthew Johnson wrote: > > On Mar 19, 2017, at 4:02 PM, Charles Srstka via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >>> On Mar 19, 2017, at 3:45 PM, Brent Royal-Gordon >> <mailto:br...@architechies.com

Re: [swift-evolution] Smart KeyPaths

> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution > wrote: > >> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >>> mailto:swift-evolution@s

Re: [swift-evolution] Smart KeyPaths

Ah, yes, that would be annoying if editing .xib files caused SourceKitService dialogs to pop up every five seconds, the way editing .swift files does. Charles > On Mar 20, 2017, at 9:39 PM, Kenny Leung via swift-evolution > wrote: > > Wouldn’t this require the Swift compiler and the original

Re: [swift-evolution] [Proposal] Factory Initializers

t; >> i would appreciate this feature. >> >> For unexperienced developers, its often hard to recognize *when* factory is >> a good fit to do the job, and how exactly approach the implementation. I >> imagine having this feature built into the language may help to cho

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

> On Mar 20, 2017, at 9:33 PM, Greg Parker via swift-evolution > wrote: > > >> On Mar 20, 2017, at 4:54 PM, Douglas Gregor > > wrote: >> >> Hello Swift community, >> >> The review of SE-0159 "Fix Private Access Levels" begins now and runs >> through March 27, 2017.

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

> On Mar 21, 2017, at 12:11 AM, Xiaodi Wu via swift-evolution > wrote: > > Charles Srstka's added comment, while intriguing, poses a problem in > argumentation. One of the points being made above about the major advantage > of new `private` over `fileprivate` is precisely that new `private` is

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

> On Mar 21, 2017, at 5:43 PM, David Hart via swift-evolution > wrote: > > That’s why protected (a feature) is on the commonly rejected proposals list Unless you’re referring to a different “commonly rejected proposals” list than the one below, this does not appear to be true: https://github

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

> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution > wrote: > > So, if four/five access modifiers are too many, which one is carrying the > least weight? Which one could be removed to simplify the scheme while > maintaining the most expressiveness? Which one doesn't fulfill even its

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

> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 5:26 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> So, if four/five access modifiers are t

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

> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 7:49 PM, Xiaodi Wu > > wrote: > >> >> On Tue, Mar 21, 2017 at 6:46 PM, Charles Srstka >

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

> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka > wrote: > >> On Mar 21, 2017, at 8:15 PM, Xiaodi Wu > > wrote: >> >> On Tue, Mar 21, 2017 at 8:00 PM, Charles Srstka >

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

> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 9:17 PM, Xiaodi Wu > > wrote: >> >> On Tue, Mar 21, 2017 at 8:31 PM, Charles Srstka >

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

> On Mar 21, 2017, at 10:42 PM, Xiaodi Wu wrote: > > On Tue, Mar 21, 2017 at 10:36 PM, Charles Srstka > wrote: >> On Mar 21, 2017, at 10:15 PM, Xiaodi Wu > > wrote: > >> >> On Tue, Mar 21, 2017 at 9:40 PM, Charles Srstka >

Re: [swift-evolution] [Proposal] [Discussion] Explicit Toll-Free Conversions

I didn’t even know the compiler still supported these implicit conversions. So, +1, I guess. Charles > On Mar 23, 2017, at 12:35 AM, Robert Widmann via swift-evolution > wrote: > > Good evening all, > > Attached is the proposal text that came out of a short discussion on Twitter >

[swift-evolution] Pitch: Partial Implementations

MOTIVATION: In current Swift, a pattern has emerged among some developers, in order to logically group parts of a class or struct’s declaration, particularly around protocols: class Foo { … } extension Foo: SomeProtocol { ... } extension Foo: SomeOtherProtocol { ... }

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 1:21 PM, Matthew Johnson wrote: > > If we wanted to allow code like this to be written we wouldn’t need a new > keyword to do it. You are proposing two things here: > > 1) Allow stored properties in same-module extensions. This has been > discussed in the past and is a

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 2:15 PM, Matthew Johnson wrote: > > What I’m suggesting is that we could accomplish the same functionality by > enhancing extensions. You can make a case that using a different keyword for > same-module extensions that are allowed to have stored properties is a good > id

Re: [swift-evolution] Pitch: Partial Implementations

> On Mar 23, 2017, at 2:45 PM, Matthew Johnson wrote: > > Sure, but this does effectively violate lexical scope boundaries as they > exist in the original source. If the yeas have it on SE-0159, and “private” is turned into “fileprivate”, the lexical scope boundaries of *everything* will be vi

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

> On Mar 23, 2017, at 8:35 PM, Matthew Johnson via swift-evolution > wrote: > > On Mar 23, 2017, at 8:27 PM, Drew Crawford > wrote: > >> >> >> >> Sent from my iPhone >> On Mar 23, 2017, at 6:41 PM, David Hart > > wrote: >> >>> I hav

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

> On Mar 24, 2017, at 11:41 AM, Drew Crawford via swift-evolution > wrote: > > I would argue that supporting whatever the programmer's chosen mental model > is actually Swift's greatest strength. We could have a language with only > reference types for example, it would be far, far simpler an

Re: [swift-evolution] [Review] SE-0160: Limiting @objc inference

> On Mar 24, 2017, at 12:09 PM, Douglas Gregor via swift-evolution > wrote: >> >> I'm actually not worried about methods so much as properties. KVC is >> completely untyped on the Objective-C side, and there are several different >> mechanisms there which use KVC with poorly validated external

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

> On Mar 26, 2017, at 11:57 AM, David Sweeris via swift-evolution > wrote: > > On Mar 26, 2017, at 08:50, David James via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> • What is your evaluation of the proposal? >> -1 as written (see below) >> >> • Is the problem being addre

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

> On Mar 26, 2017, at 8:44 PM, Brent Royal-Gordon via swift-evolution > wrote: > > So with file-based `private`, there are only two reasons to care about which > file a piece of code is in—`private` access and subjective code > organization—and these two things are usually aligned. This sente

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

> On Mar 26, 2017, at 11:21 PM, Jonathan Hull via swift-evolution > wrote: > > I wonder if there is a different type of UI solution which might help people > who hate dividing things up into lots of small files. > > I find the way that I work is to make a super large file while I work, and >

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

> On Mar 27, 2017, at 2:17 AM, Jonathan Hull wrote: > > Then you could keep it in the same file. As you said, the helper type is > tiny. > > (or once we have submodules, I suppose you could put it somewhere else in the > submodule, if desired) > > Thanks, > Jon But then the helper type’s co

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

> On Mar 27, 2017, at 12:00 PM, Ross O'Brien via swift-evolution > wrote: > > I'm considering this from a different angle. > > When we declare a type, we declare properties and functions which that type > has. > When we extend a type, we add functions to the type. (I'm including computed > pr

Re: [swift-evolution] Disallowing unreachable code

> On Mar 24, 2017, at 5:54 PM, Peter Dillinger via swift-evolution > wrote: > > I don't see anything directly relevant to this in the archives, and I haven't > prepared a detailed proposal. But I'm raising the general idea because I > recently criticized Swift 3 for allowing unreachable code

Re: [swift-evolution] Smart KeyPaths

> On Mar 29, 2017, at 7:12 PM, James Berry via swift-evolution > wrote: > >> Referencing Key Paths >> >> Forming a KeyPath borrows from the same syntax added in Swift 3 to confirm >> the existence of a given key path, only now producing concrete values >> instead of Strings. Optionals are han

[swift-evolution] Pitch: @objc attribute for top-level functions

MOTIVATION: Sometimes, it’s necessary to write a top-level C function in order to interact with some C-based code. This can come up, for example, when making a new port for a cross-platform app that implements OS-dependent functionality via C functions. More urgently, though, it also pops up in

Re: [swift-evolution] [Review #2] SE-0160: Limiting @objc inference

> On Mar 31, 2017, at 10:29 AM, Chris Lattner via swift-evolution > wrote: > > Hello Swift community, > > The second review of "SE-0160: Limiting @objc inference" begins now and runs > through April 2, 2017. The proposal is available here: > > > https://github.com/apple/swift-evolutio

Re: [swift-evolution] (Pitch) Conformance Regions

Huge +1 in general, but with one exception: > On Mar 30, 2017, at 12:07 PM, Ross O'Brien via swift-evolution > wrote: > > struct Foo > { > conformance Bar // or conformance Foo : Bar, but since the region is inside > Foo that's redundant > { > var integer : Int // visible because Foo :

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 3, 2017, at 1:34 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift Community, > > In rejecting SE-0159 > , > the core team described a potential direction we would like to

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 3, 2017, at 2:00 PM, Adrian Zubarev via swift-evolution > wrote: > > I must admit that’s a very interesting approach, however to me it feels like > fileprivate will be a really small upgrade to private when you actually need > it. That’s kind of the point, though; to reduce ‘filepriv

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 3, 2017, at 2:28 PM, David Hart via swift-evolution > wrote: > > Btw, I know what I'm going to propose is a bit crazy, but how about making > private visible to extensions even outside the file but in the same module? That’s actually what I suggested in my original post on the topic.

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 4, 2017, at 2:42 PM, Nevin Brackett-Rozinsky via swift-evolution > wrote: > > On Tue, Apr 4, 2017 at 3:30 PM, David Hart > wrote: > I agree with you. But that soft-default requires a simple and recognisable > name. That’s why I proposed SE-0159. But it got re

Re: [swift-evolution] Type-based ‘private’ access within a file

> On Apr 5, 2017, at 6:10 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Apr 5, 2017, at 2:27 PM, Tony Arnold via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I know Swift has different purposes for different people here, but >> ultimately it’s supposed to s

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

+1. This looks fantastic. Charles > On Apr 5, 2017, at 6:01 PM, Douglas Gregor via swift-evolution > wrote: > > Proposal Link: > https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md > >

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

+1. This looks fantastic. Charles > On Apr 5, 2017, at 6:56 PM, Douglas Gregor via swift-evolution > wrote: > > Hello Swift community, > > The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for > Swift" begins now and runs through April 9, 2017. The revised proposal is >

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

+1 from me. This will solve the great majority of cases where “fileprivate” is currently needed, and will facilitate the common use case of splitting a type’s implementation into multiple extensions. My only wish is that it applied to extensions in the same *module*, rather than the same *file*

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution > wrote: > > `private` works for extensions exactly how the authors of SE-0025 intended it > to do. Your comments do not address what would happen for those people who > are making use of this functionality currently to isolate method

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

> On Apr 6, 2017, at 7:48 PM, Xiaodi Wu wrote: > > On Thu, Apr 6, 2017 at 7:38 PM, Charles Srstka > wrote: >> On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> `private` works for extensions exactly how

Re: [swift-evolution] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

I suggested that a while ago. Although I still think it’s the best solution (in addition to the benefits you mentioned, partials could also contain stored properties without making the behavior of extensions inconsistent), it didn’t seem to go over very well on the list, with people balking at t

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

Yes, please. This will fill a major hole; namely, allowing us to populate collections functionally when the problem is too complex for a simple ‘map’ operation, or when the collection being built is something other than an array. Charles > On Apr 14, 2017, at 1:41 PM, Ben Cohen via swift-evolut

Re: [swift-evolution] [Pitch] Don't require & for UnsafeRawPointer

+1 Charles > On May 17, 2017, at 12:48 PM, Anders Kierulf via swift-evolution > wrote: > > I want to bring this up one last time in swift-evolution to give this issue a > chance to not fall through the cracks. Passing a value to UnsafeRawPointer > should not force that method to be mutating.

Re: [swift-evolution] [Pitch] Don't require & for UnsafeRawPointer

Reading over this again, the proposal should also mention changing withUnsafePointer(to:_:) to no longer take an inout as its first argument. Charles > On Apr 20, 2017, at 2:10 PM, Anders Kierulf via swift-evolution > wrote: > > Summary: Currently, only mutable values can be passed to UnsafeR

Re: [swift-evolution] [Pitch] Don't require & for UnsafeRawPointer

There’s also no guarantee that unsafeBitCast won’t be used to mess with any argument to *anything* in ways that it’s not supposed to. This is just one of the perils of using unsafe APIs, of which UnsafePointer is a part. By taking an UnsafePointer, however, the API is claiming it won’t mutate th

Re: [swift-evolution] [Pitch] Computed properties as aliases

> On May 25, 2017, at 1:34 PM, Xiaodi Wu via swift-evolution > wrote: > > On Thu, May 25, 2017 at 10:08 AM, Harshil Shah via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > Hi all, > > The idea behind this is to add a shorter, cleaner syntax for the common > pattern of using com

Re: [swift-evolution] [Pitch] Computed properties as aliases

> On May 25, 2017, at 9:26 PM, Hooman Mehr via swift-evolution > wrote: > > This is common when you are using façade design pattern. You use a façade to > flatten and hide the internal composition of a composite object and present > it as a single flat object. In some types of projects this co

Re: [swift-evolution] [swift-users] Plan to move swift-evolution and swift-users mailing lists to Discourse

> On Mar 20, 2017, at 11:39 AM, Jon Shier via swift-evolution > wrote: > > So when is this transition happening? The sooner the better, as Mail > can’t really handle threads with large messages, like the recent evolution > threads about Foundation serialization and decoding. It just stop

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

> On Jun 8, 2017, at 9:19 AM, David Sweeris via swift-evolution > wrote: > > #1 & #3 would violate Swift's rule about having to fully initialize all > properties in inits. > > My initial reaction is to like #2, though, assuming I understand it correctly. Assigning things to self can already b

[swift-evolution] Pitch: Allow @objc for all property declarations regardless of type

INTRODUCTION: This pitch proposes to allow the @objc keyword on all property declarations, even ones whose type cannot be represented in Objective-C. MOTIVATION: You’re thinking, “But that’s crazy. Why would you ever want to do that?” But hear me out: - In Swift 4, barring cases where it’s re

Re: [swift-evolution] Int indexing into UTF16View

> On Jun 8, 2017, at 2:35 PM, Tony Allevato via swift-evolution > wrote: > > It is an extremely rare case for a developer to know a priori what literal > numeric indices should be used when indexing into a string, because it only > applies when strings fall into a very specific format and enco

Re: [swift-evolution] [Proposal] Uniform Initialization Syntax

I prefer ‘factory’ myself. Charles > On Jun 11, 2017, at 4:04 AM, Michael Grewal via swift-evolution > wrote: > > Hey how about a new company called > Kernal*saun*$eeders*=ultimatetruecode.ORG > I have the I dream of the kings of live script support > No one ca

Re: [swift-evolution] Pitch: Allow @objc for all property declarations regardless of type

@objc broadly available would be a more elegant solution. > On Jun 10, 2017, at 11:47 AM, Charles Srstka via swift-evolution > wrote: > > INTRODUCTION: > > This pitch proposes to allow the @objc keyword on all property declarations, > even ones whose type cannot be repre

Re: [swift-evolution] [swift-dev] RFC: bridging peephole for "as" casts

+Int.max Charles > On Jun 14, 2017, at 1:24 AM, David Hart via swift-evolution > wrote: > > Very good description. It's always worth re-explaining terms like bridged > conversion to make sure every body is on the same page. But concerning the > rules at the end, I’m not quite sure I understo

Re: [swift-evolution] [Pitch] Guard/Catch

> On Jul 8, 2017, at 3:08 PM, Christopher Kornher via swift-evolution > wrote: > > I am opposed to this proposal because it muddies up the language to support > what is essentially an edge case. The standard way to exit a function early > because an exception is thrown is to make the function

[swift-evolution] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

MOTIVATION: Meet Bob. Bob is a developer with mostly C++ and Java experience, but who has been learning Swift. Bob needs to write an app to parse some proprietary binary data format that his company requires. Bob’s written this app, and it’s worked pretty well on Linux: import Foundation do {

Re: [swift-evolution] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

> On Jul 14, 2017, at 2:35 PM, John McCall wrote: > >> On Jul 14, 2017, at 1:12 PM, Charles Srstka via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> MOTIVATION: >> >> Meet Bob. Bob is a developer with mostly C++ and Java experience

Re: [swift-evolution] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

> On Jul 14, 2017, at 3:24 PM, John McCall wrote: > > We should absolutely not need to do the later autoreleases. We have logic to > autorelease objects when calling returns-inner-pointer objects on them, but > we shouldn't need to do that in safe patterns like what Data does here by > scopin

Re: [swift-evolution] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

> On Jul 14, 2017, at 3:40 PM, John McCall wrote: > > Would you mind just filing a bug with a reduced test case? > > John. Radar or bugs.swift.org ? Charles ___ swift-evolution mailing list swift-evolution@swift.org https://l

Re: [swift-evolution] Pitch: Wrap calls to NSFileHandle and NSData in autorelease pools

> On Jul 14, 2017, at 3:56 PM, John McCall wrote: > > >> On Jul 14, 2017, at 4:43 PM, Charles Srstka > > wrote: >> >>> On Jul 14, 2017, at 3:40 PM, John McCall >> > wrote: >>> >>> Would you mind just filing a bug with a reduced test c

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

+1 for the removal of ArithmeticOverflow alone. Charles > On Jul 20, 2017, at 5:31 PM, Ben Cohen via swift-evolution > wrote: > > Hi Swift community, > > Following feedback during the 4.0 preview, a handful of minor amendments have > been suggested to SE-104: Protocol-oriented integers that

Re: [swift-evolution] [Pitch] New Version of Array Proposal

Do FSAs really need special sugar, though? They won’t be an extremely heavily-used construct, but rather they’ll be occasionally used either for performance reasons or to interact with C APIs. Sure, C had a short syntax for making them, but making pointers in C was short, too, and that hasn’t be

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

I’ll take the opposite stance. Why limit this to initialization? I’d love to be able to guard assignments to *any* variable, whether it’s a property or not: func foo() { let bar: String if someCondition { guard bar = mightReturnOptional() else {

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

> On Aug 3, 2017, at 12:05 PM, Itai Ferber via swift-evolution > wrote: > > Thanks for putting these thoughts together, Jordan! Some additional comments > inline. > >> On Aug 2, 2017, at 5:08 PM, Jordan Rose > > wrote: >> >> David Hart recently asked on Twitter

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

> On Aug 21, 2017, at 11:29 AM, Robert Bennett via swift-evolution > wrote: > > If value-based generics become a thing, then you’ll be able to specify a URL > type with URL<.file> which would pretty much solve this problem. And then you could make APIs that are specific to certain schemes, an

Re: [swift-evolution] Beyond Typewriter-Styled Code in Swift, Adoption of Symbols

> On Aug 29, 2017, at 8:25 PM, Robert Bennett via swift-evolution > wrote: > > But the question is, why does this need to affect the code base? > > In the article you attached, they mention the antiquated one-line calculator > display. The issue with that display is not the data stored in the

Re: [swift-evolution] [Concurrency] async/await + actors

> On Sep 2, 2017, at 4:05 PM, David Zarzycki via swift-evolution > wrote: > >> On Sep 2, 2017, at 14:15, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> My understanding is that GCD doesn’t currently scale to 1M concurrent queues >> / tasks. > > Hi Chris!

Re: [swift-evolution] [swift-users] Swift 4.0 released!

> On Sep 19, 2017, at 9:06 PM, Ted Kremenek via swift-users > wrote: > > I am pleased to announce that Swift 4.0 has been officially released: > > https://swift.org/blog/swift-4-0-released/ > > > Swift 4 is available in Xcode 9 (which went live o

Re: [swift-evolution] Property Getter Return Statement

> On Oct 7, 2017, at 12:22 PM, Tony Allevato via swift-evolution > wrote: > > I think the important thing to consider is, what advantage would such a > feature provide *other* than to reduce keystrokes? (I don't personally think > that optimizing for keys pressed by itself should be a goal.)

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

> On Oct 24, 2017, at 5:02 PM, Slava Pestov via swift-evolution > wrote: > > Thoughts? Does anyone actually rely on this feature, instead of just > stumbling on it by accident once in a while? The main thing I can think of off the top of my head is getting the tag from the sender in an IBActi

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

I guess, but doesn’t it seem far more elegant to have a protocol for tag-containing objects? This is a feature that’s pretty heavily used… Charles > On Oct 24, 2017, at 6:06 PM, Slava Pestov wrote: > > You can implement an @objc protocol with an optional requirement, and make > NSObject confo

Re: [swift-evolution] Pitch: Deprecate/remove AnyObject method dispatch

> On Oct 25, 2017, at 10:27 AM, BJ Homer wrote: > > That would be a Cocoa-side change, since UIView, NSView, NSMenuItem, NSCell > are all Cocoa-level objects. (I’m not aware of any other type that would be > commonly passed as a ‘sender’ parameter and would have a tag.) That change > wouldn’t

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> On May 24, 2016, at 5:45 PM, Haravikk via swift-evolution > wrote: > >> On 24 May 2016, at 21:14, Leonardo Pessoa > > wrote: >> >> My first question here would be "what's the gain?" I understand >> CollectionTypes and arrays may be something different but I myself >>

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

> On May 26, 2016, at 4:47 PM, Brent Royal-Gordon via swift-evolution > wrote: > > - Abusing rawValue is just that: an abuse. In addition, enums with associated types can’t have rawValues. Why is this relevant, you may ask? Because error enums are a huge use case for something like this. Bein

[swift-evolution] Pitch: Small fix to where clauses in generics

Forgive me if this has already been proposed in one of the generics threads; I did a quick check and didn’t see anything. Currently, the code below does not compile: protocol P {} struct S: P {} extension SequenceType where Generator.Element: P { func foo() {} } func F(arr: [P]) {

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> On May 27, 2016, at 9:31 AM, plx via swift-evolution > wrote: > > For the Sequence/Collection it’s a lot of work for IMHO a rather minor > convenience, but for more-complex type associated-type relationships it could > start to pay its own way. Is it really that minor, though? For something

Re: [swift-evolution] [Pre-proposal] Replace [Foo] With CollectionType

> On May 27, 2016, at 1:53 PM, Xiaodi Wu wrote: > > Firstly, the syntax is about to get a lot cleaner. Soon, your example will be: > > func doSomething< > S: Sequence, T: Sequence, U: Sequence > >(foos: S, bars: T, bazzes: U) > where S.Element == Foo, T.Element == Bar, U.Element == Baz I wonder

Re: [swift-evolution] Enhanced existential types proposal discussion

Forgive me if this has already come up, but since we’re talking about fixing generics, I wonder if there is any solution in the pipeline for this problem: -- protocol P { func foo() } struct S: P { func foo() { print("foo") } } func doSomething(c: C) { for each in c { ea

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 29, 2016, at 5:16 PM, Austin Zheng wrote: > > I think the problem here is that P == P is true, but P : P is not (a protocol > does not conform to itself). But if you have a variable, parameter, etc. typed as P, that’s *not* the protocol, since protocols aren’t concrete entities. What

Re: [swift-evolution] Enhanced existential types proposal discussion

> On May 29, 2016, at 9:20 PM, Matthew Johnson wrote: > > On May 29, 2016, at 5:43 PM, Charles Srstka via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >>> On May 29, 2016, at 5:16 PM, Austin Zheng >> <mailto:austinzh...@gmail.com>>

Re: [swift-evolution] Enhanced existential types proposal discussion

;> >>> On May 29, 2016, at 5:43 PM, Charles Srstka via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>>> On May 29, 2016, at 5:16 PM, Austin Zheng >>>> <mailto:austinzh...@gmail.com>> wrote: &

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 28, 2016, at 8:11 PM, Brent Royal-Gordon via swift-evolution > wrote: > > But `protected` is quite different from other access levels; it does not > limit the visibility of the symbols, but rather their use. And protocols face > the same sort of problem as classes, where certain membe

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 30, 2016, at 3:42 AM, Tino Heth via swift-evolution > wrote: > >> I can't reply directly to all the points in this thread, but I will just say >> that there are ways of emulating protected in the language as it exists >> today: >> >> If the goal is to have functions that can be overr

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 30, 2016, at 11:23 AM, Tino Heth <2...@gmx.de> wrote: > >> Couldn’t you use the same reasoning to claim there shouldn’t be access >> control at all? Just add documention on methods you want to mark private >> telling users of the library not to call them! > > I guess you are making fun

Re: [swift-evolution] [Proposal] Protected Access Level

> On May 30, 2016, at 2:02 PM, Tino Heth <2...@gmx.de> wrote: > >> The purpose of access control isn’t really to keep out malicious users, >> though, it’s to prevent accidental misuse and clarify the interface. > mh, I would call this a "documenting intend" ;-) If you get the method as an autoco

Re: [swift-evolution] [Proposal] Enums with static stored properties for each case

A huge +1 on the syntax change, which I think is a colossal improvement over the current situation and adds a lot of clarity to enum declarations. Neutral on the necessity to add actual stored properties to the enums. If the new syntax were merely syntactic sugar that would effectively generate

[swift-evolution] Pitch: @required attribute for closures

MOTIVATION: As per the current situation, there is a pitfall when writing asynchronous APIs that does not occur when writing synchronous APIs. Consider the following synchronous API: func doSomething() -> SomeEnum { if aCondition { if bCondition {

Re: [swift-evolution] Pitch: @required attribute for closures

> On Jun 5, 2016, at 10:28 AM, Michael Peternell > wrote: > > This is not a good design. If you want the completion handler to be called, > you can rewrite the function to make this intent obvious: > > func doSomethingAsync(completionHandler: (SomeEnum) -> ()) { >dispatch_async(someQueue)

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 5, 2016, at 1:49 PM, Pyry Jahkola via swift-evolution > wrote: > > >> On 05 Jun 2016, at 21:26, Антон Жилин via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> The following names were suggested: NoReturn, Bottom, None, Never. >> I would pick None, because it looks

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 5, 2016, at 5:41 PM, Michael Peternell via swift-evolution > wrote: > >> Am 05.06.2016 um 20:26 schrieb Антон Жилин via swift-evolution >> mailto:swift-evolution@swift.org>>: >> >> The following names were suggested: NoReturn, Bottom, None, Never. >> I would pick None, because it look

Re: [swift-evolution] Pitch: @required attribute for closures

> On Jun 5, 2016, at 5:46 PM, michael.petern...@gmx.at wrote: > >> Am 05.06.2016 um 20:31 schrieb Charlie Monroe via swift-evolution >> mailto:swift-evolution@swift.org>>: >> >> While I agree with Michael that nowadays, a lot of stuff that doesn't need >> to be, is done async, which leads to a

Re: [swift-evolution] Pitch: @required attribute for closures

On Jun 6, 2016, at 2:49 PM, Michael Peternell wrote: > > That's really hard to answer in the general case. I think real proposals > should contain concrete, realistic examples that show the benefit of the > proposal. It's really hard to argue against a proposal if there is no such > example. U

Re: [swift-evolution] Pitch: @required attribute for closures

> On Jun 6, 2016, at 3:48 PM, michael.petern...@gmx.at wrote: > > Yes, ok... > > Well, I cannot easily make everything synchronous. I just can change it in a > way that makes a `@required` attribute "optional" ;) > > import Foundation > > enum Result { >case success(T) >case error(Erro

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 11:47 AM, Brent Royal-Gordon via swift-evolution > wrote: > >> I disagree. We are discussing how to annotate a function in some way so that >> the compiler knows that the code following it will never be executed *and* >> so a human who reads the declaration knows that it d

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 3:12 PM, Xiaodi Wu wrote: > > On Tue, Jun 7, 2016 at 2:49 PM, Michael Peternell via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > > > Am 07.06.2016 um 19:45 schrieb Charles Srstka via swift-evolution > > mailto:swift-evolu

Re: [swift-evolution] [Draft] Change @noreturn to unconstructible return type

> On Jun 7, 2016, at 3:56 PM, Xiaodi Wu wrote: > > No doubt, @noreturn is clearer today, but how much of that is because it's > what we already know? None. It’s clearer because it does exactly what it says on the tin. Show it to someone who’s familiar with the concept of functions and returnin

Re: [swift-evolution] [Pitch] Make `default` function parameter values more transparent

> On Jun 12, 2016, at 11:27 PM, Charlie Monroe via swift-evolution > wrote: > >> >> On Jun 11, 2016, at 3:35 PM, Adrian Zubarev via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I just installed the current Swift 3 snapshot to play around with it (last >> from may crashe

  1   2   3   4   >