Re: [swift-evolution] [swift-users] Discourse forum rollout next week!

:thumbsup: Charles > On Jan 10, 2018, at 2:22 PM, Nicole Jacque via swift-users > wrote: > > Hi All- > > First of all, a big thank you to everyone who has provided feedback on our > prototype Discourse forum. We are ready to move forward with the transition! > The schedule will be: > > 1/

Re: [swift-evolution] [Pitch] @static imports

> On Dec 20, 2017, at 8:56 AM, Karl Wagner via swift-evolution > wrote: > > There’s a lot of talk in the non-exhaustive enum discussion about the source > transition. So let me suggest a possible solution: @static imports. > > Basically, it seems to me like resilience is going to introduce a l

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 5:51 PM, Joe Groff wrote: > > > >> On Nov 10, 2017, at 3:45 PM, Charles Srstka > > wrote: >> >>> On Nov 10, 2017, at 5:36 PM, Joe Groff >> > wrote: >>> >>> How `MyObject.foo(_:bar:)` gets implemented is its own bu

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 5:36 PM, Joe Groff wrote: > > How `MyObject.foo(_:bar:)` gets implemented is its own business, as far as > the compiler is concerned. The compile-time name resolution for the method > isn't impacted. > > -Joe The compile-time name resolution for the method doesn’t happen

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 2:57 PM, Joe Groff wrote: > >> On Nov 10, 2017, at 12:37 PM, Charles Srstka > > wrote: >> >>> On Nov 10, 2017, at 12:04 PM, Joe Groff via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> I don't like the idea of some c

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 12:04 PM, Joe Groff via swift-evolution > wrote: > > I don't like the idea of some calls having wildly different semantics from > others; it's difficult enough to tell what exactly a call might be doing > already. Since we also lack the more obvious static "Callable" prot

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

> On Nov 8, 2017, at 10:51 PM, Charlie Monroe via swift-evolution > wrote: > > I find more limiting the ability not to declare @objc a property of a class > that doesn't inherit from NSObject: > > class Foo { > var x: Int = 0 > } > > class Bar { > var foo = Foo() // Why shouldn't

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] 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 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] 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] [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] [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] 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] (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] 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] 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] [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] 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: 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] 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: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 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

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

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

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

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

+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] [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] [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] [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

> 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

+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 #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] [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] 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] 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 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 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 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] (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] [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

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

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

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

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

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

[swift-evolution] Pitch: Range return values for String Insert/Replace methods

MOTIVATION: Swift strings support a few methods for inserting and replacing things in the middle of them: mutating func insert(_ newElement: Character, at i: String.Index) mutating func insert(contentsOf newElements: S, at i: String.Index) mutating func replaceSubrange(_ bounds: ClosedRange, w

Re: [swift-evolution] Infer types of default function parameters

> On Mar 11, 2017, at 3:17 PM, Jaden Geller via swift-evolution > wrote: > > As I understood it, omitting the type would work identically to `let` > declarations. A string literal without a type defaults to `String`. Treating > it as a generic function is a bad idea IMO. > > I don't think thi

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

On Mar 6, 2017, at 11:15 AM, Joe Groff wrote: > >> >> On Mar 4, 2017, at 3:45 PM, Charles Srstka via swift-evolution >> wrote: >> >>> On Mar 4, 2017, at 5:12 PM, Kenny Leung via swift-evolution >>> wrote: >>> >>> Speaking

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

No, that’s pretty much exactly what I was saying. Charles > On Mar 4, 2017, at 9:12 PM, Kenny Leung via swift-evolution > wrote: > > I think I understand what you’re saying, but that doesn’t seem to be what > Charles is saying in #3. > > -Kenny > > >> On Mar 4, 2017, at 6:15 PM, Jaden Gell

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

> On Mar 4, 2017, at 5:12 PM, Kenny Leung via swift-evolution > wrote: > > Speaking from a position of total ignorance here, but I’ll do it anyway :-) > > How is the implicit dynamic bridging any different from implicit static > bridging? If I have an Objective-C method like > > - (NSArray)ge

Re: [swift-evolution] Should explicit `self.` be required when providing method as closure?

> On Mar 4, 2017, at 1:09 AM, David Hart via swift-evolution > wrote: > > I encountered this precise memory leak in my code a few days ago, so I > sympathize. A second solution would be to drop function references. I think a > core team member suggested it on another thread. If I had to guess

Re: [swift-evolution] [Pitch] SE-0083 revisited: removing bridging behavior from `as`/`is`/`as?` casts

> On Mar 1, 2017, at 10:11 PM, Joe Groff via swift-evolution > wrote: > > I’d like to investigate separating Objective-C bridging from the behavior of > the as/as?/is operator family again for Swift 4. Last year, I proposed > SE–0083 >

Re: [swift-evolution] A Comprehensive Rethink of Access Levels in Swift

> On Feb 25, 2017, at 5:27 PM, Matthew Johnson via swift-evolution > wrote: > > The name that has usually been used for this is `closed`. But no word that > expresses a *restriction* is going to fit well into Swift’s access control > system. The approach of Swift’s access control system (whi

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

> On Feb 22, 2017, at 2:05 PM, Rod Brown wrote: > > I think the big argument from you, Charles, is that the progress can become > arbitrarily badly performing, depending on its use, and that could have > untold effects up the chain with KVO notifications firing for minor elements > of work? >

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

> On Feb 22, 2017, at 1:41 PM, Charles Srstka via swift-evolution > wrote: > >> * Updating completedUnitCount atomically >> >> The best practice here is to keep the progress object thread local. I think >> that updating one progress from multiple threads c

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

> On Feb 22, 2017, at 12:52 PM, Tony Parker wrote: > > It seems like the main complaints about NSProgress revolve around KVO, which > there is no question about not being right for Swift in many ways. I’m aware > of that. I think the right answer there is instead to improve KVO in Swift, > not

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

> On Feb 21, 2017, at 3:52 PM, Rod Brown wrote: > > It still holds the fundamental oddities of NSProgress that I find weird. Like > "current progress" always strikes me as very odd concept. The “current progress” bit is there mainly for source compatibility. I’d expect it would not be the norm

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

> On Feb 21, 2017, at 2:52 PM, Rod Brown wrote: > > Ah sorry! To be honest, I didn't see the part about your interoperability > with NSProgress trees! > > That said, it does seem to be a hacky solution. A better solution would be a > backing NSProgress that is linked and lazily created when ca

Re: [swift-evolution] Pitch: Much better-performing, Swift-native Progress replacement

> On Feb 21, 2017, at 5:24 AM, Rod Brown wrote: > > I applaud the idea. I too find the (NS)Progress API to be very low quality. > It seems a vestige of an earlier time when Cocoa was young and APIs that seem > like they should be simple, just... aren't. I would love to see a much better > API

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 12:53 PM, Matthew Johnson wrote: > >> >> On Feb 20, 2017, at 12:42 PM, Charles Srstka via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution

Re: [swift-evolution] [Pitch] Support for pure functions. Part n + 1.

> On Feb 20, 2017, at 10:55 AM, Michel Fortin via swift-evolution > wrote: > > a) Structs/Locals: > Structs and local variables behave similarly. You can access `let` and `var` > properties and mutate the later. What if the struct contains class ivars, including private ones that you may not

Re: [swift-evolution] [Draft] open and public protocols

> On Feb 18, 2017, at 2:41 PM, Matthew Johnson via swift-evolution > wrote: > > There are good reasons a library may not wish to allow users to add > conformances to a protocol. For example, it may not wish to expose the > conforming concrete types. While similar behavior could be accomplish

Re: [swift-evolution] [Pitch] Bridging nil to Objective-C Primitives

> On Feb 13, 2017, at 9:33 PM, Jeff Kelley via swift-evolution > wrote: > > Hi all, > > I don’t have a formal proposal written up yet, but in my continued > quest to make better-annotated Objective-C code, I had an idea for bridging > nil with primitives. Since in Objective-C we often u

  1   2   3   4   >