Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 22 Nov 2017, at 07:54, Douglas Gregor wrote: > > > >> On Nov 21, 2017, at 10:48 PM, David Hart > > wrote: >> >> >> >> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution >>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 22 Nov 2017, at 07:48, David Hart via swift-evolution > wrote: > > > > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution > > wrote: > >> >> >>> On Nov 21, 2017, at 10:37 PM, Chris

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 10:48 PM, David Hart wrote: > > > > On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution > > wrote: > >> >> >>> On Nov 21, 2017, at 10:37 PM, Chris Lattner

[swift-evolution] [Pitch] Make Optional, Array, and Dictionary conditionally Equatable

Hi all, We’re having a bit of a debate over the question of whether SE-0143 “Conditional Conformances” actually proposes any standard library changes at

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 22 Nov 2017, at 07:41, Douglas Gregor via swift-evolution > wrote: > > > >> On Nov 21, 2017, at 10:37 PM, Chris Lattner wrote: >> >> On Nov 21, 2017, at 9:25 PM, Douglas Gregor wrote: Or alternatively, one could

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 10:37 PM, Chris Lattner wrote: > > On Nov 21, 2017, at 9:25 PM, Douglas Gregor > wrote: >>> Or alternatively, one could decide to make the generics system *only and >>> forever* work on nominal types,

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Nov 21, 2017, at 9:25 PM, Douglas Gregor wrote: >> Or alternatively, one could decide to make the generics system *only and >> forever* work on nominal types, and make the syntactic sugar just be sugar >> for named types like Swift.Tuple, Function, and Optional. Either

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> Am 22.11.2017 um 06:25 schrieb Douglas Gregor via swift-evolution > : > > > >>> On Nov 21, 2017, at 9:21 PM, Chris Lattner wrote: >>> >>> >>> >>> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 9:21 PM, Chris Lattner wrote: > > > >> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution >> > wrote: >> >> >> >> Sent from my iPhone >> >> On Nov 21, 2017, at 3:46 PM,

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 7:19 PM, Douglas Gregor via swift-evolution > wrote: > > > > Sent from my iPhone > > On Nov 21, 2017, at 3:46 PM, Tony Allevato > wrote: > >> Does that mean that once structural

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Sent from my iPhone > On Nov 21, 2017, at 3:46 PM, Tony Allevato wrote: > > Does that mean that once structural types can conform to protocols, would the > core team want to remove Optional as a nominal type and just use “T?”? Yes; at least, it’s a direction we’ve

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

What about mapOrNil? > On Nov 21, 2017, at 3:00 PM, Wallacy via swift-evolution > wrote: > > Let’s think I little. If the ideia is choose the best name to explain the > function: > > If the function drop the nil values and after that does a map operation. > Names

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

Does that mean that once structural types can conform to protocols, would the core team want to remove Optional as a nominal type and just use “T?”? Or has that ship sailed because of source compatibility and you just don’t want to introduce any new nominals that shadow structurals? On Tue, Nov

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 3:05 PM, Slava Pestov wrote: > > > >> On Nov 21, 2017, at 6:02 PM, David Hart > > wrote: >> >> Can somebody explain to me what are >> nominal and structural types and why Optional should really be a

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> On 13. Nov 2017, at 05:11, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 12, 2017, at 12:55 AM, David Hart via swift-evolution >> wrote: >> >> Hello evolution folks, >> >> After the positive feedback on the idea of

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 6:02 PM, David Hart wrote: > > Can somebody explain to me what are > nominal and structural types and why Optional should really be a structural > type? Nominal types are structs, enums, protocols and classes. They have declarations in source and

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 21 Nov 2017, at 22:44, Douglas Gregor wrote: > > > >>> On Nov 20, 2017, at 10:31 PM, Chris Lattner wrote: >>> >>> >>> >>> On Nov 20, 2017, at 10:24 PM, David Hart wrote: >>> >>> >>> >>> On 21 Nov 2017, at 03:17, Chris

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

Let’s think I little. If the ideia is choose the best name to explain the function: If the function drop the nil values and after that does a map operation. Names like dropNilAndMap make sense, right? But we are talking about functions that mimics the berraviour of Functional programming

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 6:07 PM, Tony Allevato via swift-evolution > wrote: > > This is something I've wanted to look at for a while. A few weeks ago I > pushed out https://github.com/apple/swift/pull/12598 > to extend the

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

on Tue, 21 Nov 2017 11:06:04 +0100 Tino Heth <2...@gmx.de> wrote: > > > 5. func fn[foo, bar](param: T) throws -> T where T: Equatable > captures [foo, bar] { … } > > I guess it can be considered good practice to start a line with the most > important information, and move the details to the far

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 6:17 PM, Chris Lattner via swift-evolution > wrote: > > Yes, I agree, we need variadic generics before we can have tuples conform :-( Well, we don’t *have* to have variadic generics to allow structural types to conform… it just composes

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 10:31 PM, Chris Lattner wrote: > > > >> On Nov 20, 2017, at 10:24 PM, David Hart > > wrote: >> >> >> >> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution >>

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

FWIW +1 For me 'compact' means drop "empty space" and return data items in the same order. I'd like to keep names exactly 'compact/compactMap' instead of 'compacted/compactedMap', but OK to have the latter if 'compact' will not be accepted as 'terms of art'. Vladimir. On 21.11.2017 8:47,

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 21, 2017, at 9:06 AM, David Hart wrote: > >>> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution >>> > wrote: >>> Yes, I agree, we need variadic generics before we can have tuples conform

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On 21 Nov 2017, at 07:31, Chris Lattner wrote: > > > >> On Nov 20, 2017, at 10:24 PM, David Hart > > wrote: >> >> >> >> On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution >>

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

On Tue, Nov 21, 2017 at 8:43 AM Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote: > In Scala they just define Tuple1, Tuple2, ... up to 22 (I think). > Eliminates the need for variadic generics and works fine in practice in > Scala. > > In Swift this approach is possibly

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

In Scala they just define Tuple1, Tuple2, ... up to 22 (I think). Eliminates the need for variadic generics and works fine in practice in Scala. In Swift this approach is possibly unacceptable, since having to write: extension Tuple1 ... extension Tuple2 ... ... extension

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 11:32 PM, Kelvin Ma via swift-evolution > wrote: > > a good idea on paper, a disastrous one in practice. What happens if every > geometry library declares their own Point type? we’d end up with the same situation we have now where everyone

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> Am 21.11.2017 um 07:32 schrieb Kelvin Ma : > > a good idea on paper, a disastrous one in practice. What happens if every > geometry library declares their own Point type? Well, if I really had the need to use several geometry libraries at once I would have to convert,

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

I have a question regarding the general term "compact" vs something more specific like "remove nil" : Could we imagine other usages on different types for "compact" ? map / flatmap has the whole category theory behind it, making it meaningful for many different types. "Filter" is also generic,

Re: [swift-evolution] [Pitch] Improving capturing semantics of local functions

> 5. func fn[foo, bar](param: T) throws -> T where T: Equatable captures > [foo, bar] { … } I guess it can be considered good practice to start a line with the most important information, and move the details to the far right, so that they don’t distract the hasty reader. I’m not sure if the

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

My favorite would be a variation of Scalas choice (collect / collectResults). The word compact (or similar choices like condense, squeeze, pack, compress…) always remind me on compression — my first association of „compact“ would be a transform that turns [1, 2, 2, 3] into [1, 2, 3] (like the

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

I have several questions/issues in this new iteration: • Why does DynamicCallableWithKeywordsToo inherit from DynamicCallable? For an interop layer for Python-style languages, we would be interested in providing conformance to DynamicCallableWithKeywordsToo (like you did in your example), but

Re: [swift-evolution] [Pitch #2] Introduce User-defined "Dynamic Member Lookup" Types

I’m very happy with this new version of the proposal. Splitting into two protocols makes a lot of sense - the JSON example alone is argument enough. To bike-shedding: while I understand the need to keep the identifier names verbose, I would prefer the subscript label to be more representative