Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

On Sat, Nov 11, 2017 at 12:15 AM, Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote: > > Personally I like the flexibility provided by the associatedtype, but I > also recognize it won't be incredibly useful for enums — more so if we > wanted to provide e.g.

Re: [swift-evolution] JSONEncoder: Key strategies

> On Nov 9, 2017, at 10:00 AM, Itai Ferber wrote: > > Hi Brent, > > Perhaps the wording would be better phrased as "boundary from > non-uppercase-character to uppercase-character", i.e. numbers and Emoji are > treated the same as lowercase characters and are included in the

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> Personally I like the flexibility provided by the associatedtype, but I also > recognize it won't be incredibly useful for enums — more so if we wanted to > provide e.g. UInt8.allValues, whose ideal implementation might be "return > 0...UInt8.max". So I could see allowing allValues to be any

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

> On Nov 10, 2017, at 9:10 PM, Brent Royal-Gordon > wrote: > Leaving the "should we do it at all" question aside… Thanks, most of the comments in this thread haven’t been constructive at all, I’m glad to get one that is :-) >> On Nov 10, 2017, at 9:37 AM, Chris Lattner

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

Leaving the "should we do it at all" question aside… > On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution > wrote: > > We propose introducing this protocol to the standard library: > > protocol DynamicCallable { > associatedtype DynamicCallableArgument

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

> On Nov 10, 2017, at 6:12 PM, Slava Pestov via swift-evolution > wrote: > > > >> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution >> > wrote: >> >> Setting this aside, I’m very curious

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

On Nov 10, 2017, at 6:05 PM, Slava Pestov via swift-evolution wrote: >> On Nov 10, 2017, at 6:01 PM, Chris Lattner wrote: >> >> It is. It is strictly sugar, as mentioned in the proposal. > > All new code has a cost. Indeed, I’m quite aware of

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

> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution > wrote: > > Setting this aside, I’m very curious to hear whether type providers influence > your thinking after you’ve had a chance to look into them. I have always > thought they were very cool.

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

Sent from my iPad > On Nov 10, 2017, at 7:41 PM, Chris Lattner wrote: > > >> On Nov 10, 2017, at 11:25 AM, Matthew Johnson via swift-evolution >> wrote: >> People have reasonably asked for the ability to make their own

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

> • What is your evaluation of the proposal? -1 Code churn, new function name has the same issues as the old one. Benefits small. It is also likely that those suffering with the String collectionifying will have already solved their issues before this update could be introduced. > • Is the

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

> On Nov 10, 2017, at 6:01 PM, Chris Lattner wrote: > > It is. It is strictly sugar, as mentioned in the proposal. All new code has a cost. > I do not expect any SIL or IRGen changes associated with this proposal, just > type checker changes. The type checker changes

Re: [swift-evolution] async void

I’m not sure that answered my questions. Can I do this? let asyncClosure:() async -> Void = { await doSomethingAsync() } // Can you declare an async closure variable? beginAsync(asyncClosure) What about this? let syncClosure:() -> Void = { doSomethingSync() } beginAsync(syncClosure) // Can

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

On Nov 10, 2017, at 5:51 PM, Slava Pestov via swift-evolution wrote: > Hi Chris, > >> On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution >> > wrote: >> >> Hello all, >> >> I have a couple of

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

> On Nov 10, 2017, at 5:37 PM, Susan Cheng via swift-evolution > wrote: > > Hi all, > > I have few problems with this proposal. > > How we guarantee the arguments type are what we need? > If we passing the type to the dynamicCall that are not acceptable, what will

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

Hi Chris, > On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution > wrote: > > Hello all, > > I have a couple of proposals cooking in a quest to make Swift interoperate > with dynamically typed languages like Python better. Instead of baking in > hard

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

On Nov 10, 2017, at 11:42 AM, Joe Groff via swift-evolution wrote: >> >>> On Nov 10, 2017, at 10:57 AM, Alejandro Martinez via swift-evolution >>> wrote: >>> >>> This seems a really interesting solution Chris. >>> Similar to what Joe

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

> On Nov 10, 2017, at 11:25 AM, Matthew Johnson via swift-evolution > wrote: > >>> >>> People have reasonably asked for the ability to make their own >>> function-like types in the past, such that "myvalue(...)" behaves like >>> sugar for "myvalue.call(...)" or

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

Hi all, I have few problems with this proposal. How we guarantee the arguments type are what we need? If we passing the type to the dynamicCall that are not acceptable, what will happened? Should we always write the dynamicCall as a throwing function to check the precondition? Instead of

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

> On Nov 10, 2017, at 4:12 PM, Charles Srstka wrote: > >> 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

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:

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

> 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 business, as far as >> the compiler is concerned. The compile-time name resolution

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

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

> On Nov 10, 2017, at 3:27 PM, Charles Srstka wrote: > >> 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

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

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

> On Nov 10, 2017, at 4:07 AM, Tino Heth via swift-evolution > wrote: > > >> The “think of optionals as collections” explanation is a good way to help >> people who are confused by the overload. But an even better way would be to >> not have a confusing overload

Re: [swift-evolution] [swift-dev] Re-pitch: Deriving collections of enum cases

> On Nov 6, 2017, at 2:54 AM, Jacob Bandes-Storch via swift-dev > wrote: > > Over a year ago, we discussed adding a magic "allValues"/"allCases" static > property on enums with a compiler-derived implementation. The original > proposal PR

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

> On Nov 10, 2017, at 12:37 PM, Charles Srstka wrote: > >> 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

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

> On Nov 10, 2017, at 12:16 PM, Goffredo Marocchi wrote: > > > Sent from my iPhone > >> On 10 Nov 2017, at 19:42, Joe Groff via swift-evolution >> wrote: >> >> Through great pain and community anguish, we pushed ourselves to a model >> where

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

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

Sent from my iPhone > On 10 Nov 2017, at 19:42, Joe Groff via swift-evolution > wrote: > > Through great pain and community anguish, we pushed ourselves to a model > where argument labels are parts of the declaration name, not part of the call > argument Hey Joe,

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

> On Nov 10, 2017, at 11:20 AM, Chris Lattner via swift-evolution > wrote: > > >> On Nov 10, 2017, at 10:57 AM, Alejandro Martinez via swift-evolution >> wrote: >> >> This seems a really interesting solution Chris. >> Similar to what

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

> On Nov 10, 2017, at 1:19 PM, Chris Lattner via swift-evolution > wrote: > >> On Nov 10, 2017, at 10:51 AM, Joe Groff via swift-evolution >> > wrote: >>> Since we also lack the more obvious static

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

> On Nov 10, 2017, at 10:57 AM, Alejandro Martinez via swift-evolution > wrote: > > This seems a really interesting solution Chris. > Similar to what Joe mentions I think this would also be appreciated by > the community to make even nicer DSLs in Swift, which may or

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

> On Nov 10, 2017, at 10:51 AM, Joe Groff via swift-evolution > wrote: >> >>> Since we also lack the more obvious static "Callable" protocol idea to give >>> even well-typed call syntax to user-defined types, this also seems like >>> it'd be easily abused for that

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

Sent from my iPad > On Nov 10, 2017, at 12:51 PM, Joe Groff via swift-evolution > wrote: > > > >> On Nov 10, 2017, at 10:41 AM, Chris Lattner wrote: >> >> On Nov 10, 2017, at 10:03 AM, Joe Groff wrote: >>> >>> I don't like

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

This seems a really interesting solution Chris. Similar to what Joe mentions I think this would also be appreciated by the community to make even nicer DSLs in Swift, which may or may not be a good side effect of the proposal. Also, I'm just wondering, how much complication adds this to the

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

> On Nov 10, 2017, at 10:41 AM, Chris Lattner wrote: > > On Nov 10, 2017, at 10:03 AM, Joe Groff 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

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

On Nov 10, 2017, at 10:03 AM, Joe Groff 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. This isn’t particularly useful feedback. Can you elaborate

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

Object that are functions too, Amazing! I wanted that in Javascript for a while! On Nov 10, 2017, 1:04 PM -0500, 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

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

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" protocol idea to give even well-typed call syntax to user-defined types, this also

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

> I prefer to think of it this way: it does a mapping, and keeps the results > where the closure did not return nil. In the example given earlier, the > closure returned Optional.some(nil), which is not “nil”. Exactly; therefore, flatMap can even „create“ nil values… Filters in the

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

Hello all, I have a couple of proposals cooking in a quest to make Swift interoperate with dynamically typed languages like Python better. Instead of baking in hard coded support for one language or the other, I’m preferring to add a few small but general purpose capabilities to Swift. This

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

> On Nov 10, 2017, at 4:07 AM, Tino Heth <2...@gmx.de> wrote: > > >> The “think of optionals as collections” explanation is a good way to help >> people who are confused by the overload. But an even better way would be to >> not have a confusing overload in the first place. > With the

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

https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md +1 to change it (but the filterMap doesn't' seem perfect neither) • What is your evaluation of the proposal? I'm in favour of renaming that specific variant of flatMap but I'm not 100% that filterMap is

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

On 10.11.2017 18:37, BJ Homer via swift-evolution wrote: On Nov 10, 2017, at 5:07 AM, Tino Heth <2...@gmx.de> wrote: A: Well, it does a mapping, and then applies a filter to get rid of nils, I prefer to think of it this way: it does a mapping, and keeps the results where the closure did

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

> On Nov 10, 2017, at 5:07 AM, Tino Heth <2...@gmx.de> wrote: > > A: Well, it does a mapping, and then applies a filter to get rid of nils, I prefer to think of it this way: it does a mapping, and keeps the results where the closure did not return nil. In the example given earlier, the

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

> The “think of optionals as collections” explanation is a good way to help > people who are confused by the overload. But an even better way would be to > not have a confusing overload in the first place. With the renaming, confusion might strike less often, but with bigger impact (free

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

> I’m personally grateful that Swift reminds me that, for example, I need the > question mark in view.gestureRecognizers?.count. It would be maddening if > view.gestureRecognizers.count compiled, and always returned either 0 or 1. > Imagine it! > view.gestureRecognizers.count // returns 0

Re: [swift-evolution] update on forum

That sounds great to me. I don’t see December as a promise, and as I already mentioned in the other thread, that’s totally fine by me. I think it’s only fair if I say that a little bit more transparency on what’s going on with the forum is already enough for the community. I’d say we should

Re: [swift-evolution] async void

> I’m not sure how the proposed design handles type checking for async > closures. Is async part of the type? Can I declare a local closure variable > as async? What are the rules for conversion between async and non-async > closures? Is it a warning or error to use a closure literal without an