[swift-evolution] extension of AnyObject

Hi All. I just discovered that you can’t write an extension on AnyObject. What’s the reasoning behind this? I’m trying to write my own version of KeyValueObserving, and it would be really nice to be able to write self.observe(someObject, keyPath) { blah de blah } from

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

2017, at 9:26 PM, Kenny Leung via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> Hi All. >> >> I’d like to help as well. I have fun with operators. >> >> There is also the issue of code securit

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

Hi All. I’d like to help as well. I have fun with operators. There is also the issue of code security with invisible unicode characters and characters that look exactly alike. (They should make a Coding font that ensures all characters look different.) Was that ever resolved? Googling, I

Re: [swift-evolution] Question about async await

Here’s more stuff I found on how this could work. It’s slowly becoming less murky to me. http://blog.stephencleary.com/2013/11/there-is-no-thread.html -Kenny > On Sep 20, 2017, at 7:19 AM, Adam Kemp via swift-evolution >

Re: [swift-evolution] Enums and Source Compatibility

t is not part of this proposal, and what > you're describing isn't really an enum. > > Jordan > > >> On Sep 16, 2017, at 15:51, Kenny Leung via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>

Re: [swift-evolution] Enums and Source Compatibility

7, at 15:35, Kenny Leung via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> In general, I agree with everything in the proposal. >> >> I’d like to propose these alternative extensions for clients: >>

Re: [swift-evolution] Enums and Source Compatibility

tions that need to be added to the connection dictionary. It would be nice if they could just extend ConnectionDictionaryKey with new cases. -Kenny > On Sep 16, 2017, at 3:35 PM, Kenny Leung via swift-evolution > <swift-evolution@swift.org> wrote: > > In general,

Re: [swift-evolution] Enums and Source Compatibility

In general, I agree with everything in the proposal. I’d like to propose these alternative extensions for clients: 1) As a client of an enum, I’d like to know in the future when a new value has been added to an enum, since I may have to do something about it. How about adding the “exhaustive”

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

I found a decent description about async/await here: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/ So it’s much more like runloop based callbacks in Foundation that

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

synchronous API code and continue using libdispatch? What am I missing? -Kenny > On Sep 8, 2017, at 2:33 PM, David Hart <da...@hartbit.com> wrote: > > >> On 8 Sep 2017, at 20:34, Kenny Leung via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolu

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

Hi All. A point of clarification in this example: func loadWebResource(_ path: String) async -> Resource func decodeImage(_ r1: Resource, _ r2: Resource) async -> Image func dewarpAndCleanupImage(_ i : Image) async -> Image func processImageData1() async -> Image { let dataResource = await

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

Once again, the counter-argument is the the same. Before there was Swift, this is exactly what we would do, and it was never a surprise. I would say the semantics of wrapped API should be taken from the viewpoint of the target language (ObjC), and not from the viewpoint of Swift. -Kenny > On

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

bjective-C and not a struct. There is already one level of decision when >> translating to objc in that regard. Switching between reference >> semantics/class and value semantics because of optionality is surprising. >> >> On Mon, May 15, 2017 at 5:52 AM, Kenny Leung via swift-evol

Re: [swift-evolution] Swift's Optional Int as NSNumber in Objective-C

> On May 12, 2017, at 9:56 AM, John McCall via swift-evolution > wrote: > Exporting Int? as an optional NSNumber does not feel obvious and idiomatic > when we would export Int as NSInteger. It feels like reaching for an > arbitrary solution. I don’t understand

Re: [swift-evolution] Smart KeyPaths

template and keypaths that were archived to a file, > similar to a .nib file? > > >> On Mar 20, 2017, at 7:28 PM, Joe Groff via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >>> On Mar 20, 2017, at 4:01 PM, Kenny Leung via swift-

Re: [swift-evolution] Smart KeyPaths

Hi All. I’m not sure I’m understanding this proposal properly. In (old) Cocoa, two places where key paths were used extensively was EOF/CoreData, and WebObjects. I’m wondering how Smart KeyPaths will solve these two problems: 1. fetching data from a database and stuff it into objects that are

Re: [swift-evolution] [Proposal] Foundation Swift Archival & Serialization

Hi All. Forgive me if I missed it - I haven’t read the proposal in full detail - but it seems to make no mention of archiving graphs with circular references. Is this implicitly supported, or explicitly unsupported? While we’re at it, my only real exposure to archiving is through Foundation,

Re: [swift-evolution] Code blocks and trailing closures

I have proposed that a different keyword be used to return out of blocks. In Objective-C, I have a #define that aliases “blockreturn” and I use that exclusively in breaking out of blocks. -Kenny > On Mar 15, 2017, at 3:35 AM, Rien via swift-evolution > wrote: > >

Re: [swift-evolution] Swift null safety questions

For my own part, I never want to use “!” in my code, and I’m sticking to it pretty well. It has been said many times that we don’t want to create different dialects of Swift, and I agree. Would it be considered a different dialect to add a compiler option that forbids the use of “!” in my own

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

Is callback an autoclosure, or just a regular argument? -Kenny > On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution > wrote: > > Hi list members, > > During code review today, I noticed a really subtle memory leak that looked > like: > >

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

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)getAllSuctionBalls It would get translated into func getAllSuctionBalls() ->

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

So this proposal would not only change the meaning of “as”, but would require changing all bridged Objective-C API to remove any implicit conversions? -Kenny > On Mar 4, 2017, at 3:45 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: > >> On Mar 4, 2017, at 5:12 PM, Ken

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

uage boundary (via the importer). The keyword `as` would no longer > invoke bridging behavior, but would simply provide extra static type > information to help with inference. > > Cheers, > Jaden Geller > >> On Mar 4, 2017, at 4:33 PM, Kenny Leung via swift-evolution &

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

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)getAllSuctionBalls It would get translated into func getAllSuctionBalls() ->

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

Is callback an autoclosure, or just a regular argument? -Kenny > On Mar 3, 2017, at 1:14 PM, Alex Johnson via swift-evolution > wrote: > > Hi list members, > > During code review today, I noticed a really subtle memory leak that looked > like: > >

Re: [swift-evolution] A compiler option to warn if a closure captures a strong reference to a class instance?

I’m back to writing Objective-C again, and it is actually warning you about possible reference cycles in your closures. I’m for Swift doing the same. -Kenny > On Feb 20, 2017, at 3:22 AM, Lauri Lehmijoki via swift-evolution > wrote: > > I'm developing an

Re: [swift-evolution] A concern

I listened to this podcast, and it is fantastic - I’m going to listen to it again. I used to have the same reservations about the directions that Swift was going in, but one thing Chris said in the podcast really changed my mind: the idea of progressively revealing complexity to the user. At

Re: [swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

It would also enable the testing of fatal conditions, which would be great. -Kenny > On Jan 16, 2017, at 5:25 PM, Chris Lattner via swift-evolution > wrote: > > >> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution >>

Re: [swift-evolution] guard let x = x

A big YES to this! As long as "the scope guarded by the condition” means everything after the guard statement, and not everything inside an if statement. -Kenny > On Oct 31, 2016, at 6:37 PM, Joe Groff via swift-evolution > wrote: > > Sorry for piling onto the

Re: [swift-evolution] guard let x = x

the history, is the proposal to keep replace >> guard or still keep guard keyword and create a new unwrap? If unwrap is >> added the guard keyword should just be removed. >> >> Alvarado, Joshua >> >> On Oct 31, 2016, at 12:49 PM, Xiaodi Wu via swift-evolution

Re: [swift-evolution] guard let x = x

> Alvarado, Joshua > > On Oct 31, 2016, at 12:49 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > >> Because "guard" already means something... >> >> >> On Mon, Oct 31, 2016 at 13:45 Kenny Leung via swift-evolutio

Re: [swift-evolution] guard let x = x

ion to guarding > > -- E > >> On Oct 31, 2016, at 12:30 PM, Kenny Leung via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Why have the “unwrap” keyword at all? Isn’t “guard” the keyword? >> >> guard blah else { >> } >

Re: [swift-evolution] guard let x = x

Why have the “unwrap” keyword at all? Isn’t “guard” the keyword? guard blah else { } -Kenny > On Oct 28, 2016, at 3:34 PM, Erica Sadun via swift-evolution > wrote: > > >> On Oct 26, 2016, at 11:39 AM, Chris Lattner via swift-evolution >>

Re: [swift-evolution] [Proposal] Enums with stored properties

I’ve wondered this for a while now. Why must enums implement RawRepresentable? -Kenny > On Oct 12, 2016, at 4:37 AM, Karl via swift-evolution > wrote: > > You can already use structs as raw types. You just have to implement the > RawRepresentable conformance

Re: [swift-evolution] [Proposal] Enums with stored properties

This is the way Java enumerations work. https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html I think it is a good model, and I think Swift enumerations should also work the same way. An enumeration is a finite set of things. It’s really inconvenient to have to limit those things to

Re: [swift-evolution] [swift-evolution-announce] [Accepted] SE-0140: Bridge Optional As Its Payload Or NSNull

Maybe that could be: func funkyFunc(getDown :Any?) -Kenny > On Sep 12, 2016, at 4:48 PM, Greg Parker via swift-evolution > wrote: > > >> On Sep 12, 2016, at 3:39 PM, Douglas Gregor wrote: >> >> As an amendment to SE-0140, Swift will produce a

Re: [swift-evolution] InternalString class for easy String manipulation

9:33 AM, Kenny Leung via swift-evolution > <swift-evolution@swift.org> wrote: > > > >> Just because you are using UTF-8 as the internal format, it does not mean > >> that universal support is guaranteed. > > All I meant was this, and nothing more. If the i

Re: [swift-evolution] InternalString class for easy String manipulation

>> Just because you are using UTF-8 as the internal format, it does not mean >> that universal support is guaranteed. All I meant was this, and nothing more. If the internal format was UTF-8, and you were using a filesystem whose filenames were UTF-16, you would have the same problems. -Kenny

Re: [swift-evolution] InternalString class for easy String manipulation

> On Aug 17, 2016, at 1:57 PM, William Sumner wrote: > You may be interested in this article by Mike Ash, which gives a rationale > for the String API, including why indexes aren't simple integers: >

Re: [swift-evolution] InternalString class for easy String manipulation

remaining = matchRange.upperBound.. On Aug 17, 2016, at 1:34 PM, Kenny Leung via swift-evolution > <swift-evolution@swift.org> wrote: > > >> William Sumner says: >> Can you be more specific about the improvements you’d like to see? Based on >> an earlier message, you want

Re: [swift-evolution] InternalString class for easy String manipulation

> William Sumner says: > Can you be more specific about the improvements you’d like to see? Based on > an earlier message, you want to be able to use subscripting on strings to > retrieve visual glyphs, but you can do this now via the .characters property, > which presents a view of the

Re: [swift-evolution] InternalString class for easy String manipulation

internal representation, wouldn’t this be a glyph-based indexing system? -Kenny > > -Shawn > > On Wed, Aug 17, 2016 at 12:15 PM Kenny Leung via swift-evolution > <swift-evolution@swift.org> wrote: > It seems to me that UTF-8 is the best choice to encode strings in English

Re: [swift-evolution] InternalString class for easy String manipulation

g developers is just going to lead to > software that screws up in situations the developer doesn't anticipate, > as F+¬lix notes above. > > Zachary > > On Wed, Aug 17, 2016, at 09:40 AM, Kenny Leung via swift-evolution > wrote: >> I understand that the most friendly approach may

Re: [swift-evolution] InternalString class for easy String manipulation

ters in the A-Z range. (I live in the US and I can attest > that this is still very common.) > > You could make a point too that better facilities to parse strings would > probably address this issue. > > Félix > >> Le 15 août 2016 à 10:52:02, Kenny Leung via swift-

Re: [swift-evolution] InternalString class for easy String manipulation

I agree with both points of view. I think we need to bring back subscripting on strings which does the thing people would most commonly expect. I would say that the subscripts indexes should correspond to a visual glyph. This seems reasonable to me for most character sets like Roman, Cyrillic,

Re: [swift-evolution] [Pitch] Make NSNotification names a protocol like ErrorProtocol

Yes, this is the solution that I’m using, but: 1. I think following the pattern of ErrorProtocol would be better 2. It doesn’t explain why I can use String in one instance and not the other when they are both typed the same: // Can use String or Notification.Name @nonobjc final public func

[swift-evolution] [Pitch] Make NSNotification names a protocol like ErrorProtocol

Hi All. While converting to Swift3, my biggest hurdle was figuring out what to do with a custom NSNotification. In Objective-C, it’s a plain NSString, and the same in Swift2. I assumed in Swift3 that it worked like ErrorProtocol and errors as enums, but as it turns out, you need to create a

Re: [swift-evolution] Setter methods for vars

I don’t understand how ApiClient().fetchUsers().then(#set(users)) leads to ApiClient().fetchUsers().then(displayUsers) Could you clarify with a more extensive example? What does the function then() do? -Kenny > On Jun 28, 2016, at 11:18 AM, Austin Feight via swift-evolution >

Re: [swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

at 17:37, Kenny Leung via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> What does surprise me is that Swift String bridges directly into “char *” >> arguments in C as nul-terminated C strings, apparently preserving unicode >> and all. I

[swift-evolution] [Pitch] Remove transparent bridging between Swift strings and char *

Hi All. In the spirit of Chris’ focus on Swift 3 message… I’ve been working on calling C code that takes “const char * const *” arguments, and it ain’t easy, but that can be left for a future proposal… What does surprise me is that Swift String bridges directly into “char *” arguments in C as

Re: [swift-evolution] [Proposal] A more liberal placement of defer

This proposal runs counter to the spirit of what defer seems to be meant for in the first place. It’s to save you forgetting to do something (like closing a stream) before you exit a block of code. If you push it down in the code to after the return, then you might as well have just put the

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0084: Allow trailing commas in parameter lists and tuples

I am against this proposal. - I think it makes the code look ugly and incomplete when there is a trailing comma - I much prefer the counter-proposal which would allow newline to be the separator for items in a list. - in general, it’s much better when you can remove something from your code

Re: [swift-evolution] Carriage Return in Collection Array Literal Initializer

This is brilliant! If semicolons are optional, why not commas? -Kenny > On Apr 24, 2016, at 2:40 PM, Ross O'Brien via swift-evolution > wrote: > > There was a discussion some time ago about making the comma of the last entry > optional, because adding entries

Re: [swift-evolution] SE-0062 Referencing Objective-C key-paths

Hi All. Aeons ago, I was on the team that invented key paths. There were some pretty major performance issues: - the key path had to be separated into its individual components, requiring processing time and generating a bunch of garbage - the obvious thing to do would have been to parse the

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

I much prefer the Java style of enums, which are essentially classes limited to a fixed set of instances. In Java, Suit would look like this: public enum Suit { Hearts("♥", true), Spades("♠", false), Diamonds("♦", true), Clubs("♣", false); String description; boolean isRed;

Re: [swift-evolution] Make non-void functions @warn_unused_result by default

Hi All. Being naive here (also very difficult to say this clearly and succinctly), but why is this the choice of the writer of the function rather than the person using the function? That is, I would think that if I were worried about unused return results in my code, I would have some kind

Re: [swift-evolution] [Review] Require self for accessing instance members

PM, Kenny Leung via swift-evolution > <swift-evolution@swift.org> wrote: > >> * What is your evaluation of the proposal? > > +1 for it. > >> * Is the problem being addressed significant enough to warrant a change >> to Swift? > > Yes. I feel