Re: [swift-evolution] Python Interop with Swift 4+

> I think you’re missing the idea here: the idea isn’t to provide exactly > syntax mapping of Ruby (or Python) into Swift, it is to expose the underlying > semantic concepts in terms of Swift’s syntax. In the case of Python, there > is a lot of direct overlap, but there is also some places wh

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

Hi all, I’ve significantly revised the ‘dynamic member lookup’ pitch, here’s the second edition: https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 I’ve incorporated some minor changes to it: - I’ve made it possible to provide read-only dynamic members. - I’ve added an example JSON

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

a good idea on paper, a disastrous one in practice. What happens if every geometry library declares their own Point type? On Tue, Nov 21, 2017 at 1:15 AM, Thorsten Seitz wrote: > > > Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution < > swift-evolution@swift.org>: > > when SE-185 >

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

> On Nov 20, 2017, at 10:24 PM, David Hart wrote: > > > > On 21 Nov 2017, at 03:17, Chris Lattner via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> Yes, I agree, we need variadic generics before we can have tuples conform :-( >> >> At the end of the day, you want to be a

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

> 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 :-( > > At the end of the day, you want to be able to treat “(U, V, W)” as sugar for > Tuple just like we handle array sugar. When that is pos

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

> Am 21.11.2017 um 02:39 schrieb Kelvin Ma via swift-evolution > : > > when SE-185 went through swift evolution, it was agreed that the next logical > step is synthesizing these conformances for tuple types, though it was left > out of the original proposal to avoid mission creep. I think now

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

> On Nov 20, 2017, at 10:07 PM, Chris Lattner via swift-evolution > wrote: > > Hi All, > > I’ve significantly revised the ‘dynamic callable’ pitch, here’s a second > edition: Ugh, the actual correct link is: https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d > > I’ve incorpo

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

On Nov 20, 2017, at 6:12 PM, Chris Lattner via swift-evolution wrote: >> Separating method calls from property accesses solves the problem >> >> Brent wrote: >>> If we had separate subscripts for methods and properties, then the property >>> subscript could immediately call the appropriate gett

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

Hi All, I’ve significantly revised the ‘dynamic callable’ pitch, here’s a second edition: https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 I’ve incorporated a bunch of feedback from the first round of discussion: - I’ve significantly increased the motivation section, talking ab

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

> Am 21.11.2017 um 04:00 schrieb Chris Lattner via swift-evolution > : > > >> On Nov 12, 2017, at 8:52 PM, Slava Pestov via swift-evolution >> wrote: >> >> >> func fn(param: T) throws -> T where T : Equatable [foo, bar] { … } > > +1, potentially adding a context sensitive keyword like “ca

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

+1 > Am 20.11.2017 um 21:32 schrieb Jon Shier via swift-evolution > : > > This is why I really like compact/compactMap. > >>> On Nov 20, 2017, at 3:31 PM, John McCall via swift-evolution >>> wrote: >>> On Nov 20, 2017, at 12:22 PM, BJ Homer wrote: On Nov 20, 2017, at 10:09 AM, Dre

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

On Nov 20, 2017, at 7:15 PM, Michel Fortin via swift-evolution wrote: >>> As in `SupplementalDynamicMemberLookupProtocol` and >>> `supplementalDynamicMember` for the subscript. >> >> I’m totally open to suggestions for a better name, but I don’t see what >> “Supplemental” is adding here. Reca

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 20, 2017, at 11:14 PM, Drew Crawford wrote: > > It would improve the important clients without harming other clients to use > the following implementation for our type: if the sorted accessor is used > before the unsorted one, sort the underlying storage, and then serve that > until

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> How so? It seems that encapsulation is orthogonal to reference/value > semantics. Consider this type public struct Mailbox {     private var _messages: [String]     public mutating func append(message: String) { _messages.append(message)}     public var messages: [String] { return _messages}  

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

> Le 20 nov. 2017 à 21:22, Chris Lattner a écrit : > >> On Nov 16, 2017, at 4:49 AM, Michel Fortin via swift-evolution >> wrote: >> >> I think this protocol and its subscript need a better name. From a user of >> the class point of view, the subscript looks like you can retrieve the >> membe

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

> On Nov 12, 2017, at 8:52 PM, Slava Pestov via swift-evolution > wrote: > > > func fn(param: T) throws -> T where T : Equatable [foo, bar] { … } +1, potentially adding a context sensitive keyword like “capturing” before it. > I think #4 is ambiguous with array literals unfortunately. > > P

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

> On Nov 12, 2017, at 8:11 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> >> Secondly, this proposal suggests allowing the same capture list syntax from >> closures in local functions. Capture lists would still be invalid in >> top-level and member functions. > > > I think this i

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

On Nov 20, 2017, at 6:31 PM, Tony Allevato wrote: > > So (borrowing C++-ish notation), a function of type `(Args...) -> Result` > would become sugar for something like `Function`? That > certainly makes sense. Yep > How would throw-ness be handled—would we need ThrowingFunction and Function,

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

On Nov 20, 2017, at 6:30 PM, Kelvin Ma via swift-evolution wrote: > > can we go the route of SE-15 and just synthesize up to some sensible n = 7 or > whatever. i feel like this list has a habit of going “but it would be a lot > better to add X if we just wait until Y is a thing first” ignoring

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

So (borrowing C++-ish notation), a function of type `(Args...) -> Result` would become sugar for something like `Function`? That certainly makes sense. How would throw-ness be handled—would we need ThrowingFunction and Function, with the ability to coerce Function -> ThrowingFunction? (Async might

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

can we go the route of SE-15 and just synthesize up to some sensible n = 7 or whatever. i feel like this list has a habit of going “but it would be a lot better to add X if we just wait until Y is a thing first” ignoring that Y will probably not be a thing for the forseeable future and we really ne

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

> On Nov 16, 2017, at 4:49 AM, Michel Fortin via swift-evolution > wrote: > > I think this protocol and its subscript need a better name. From a user of > the class point of view, the subscript looks like you can retrieve the > members of the class, whereas in reality you'll only get the ones

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

Yes, I agree, we need variadic generics before we can have tuples conform :-( At the end of the day, you want to be able to treat “(U, V, W)” as sugar for Tuple just like we handle array sugar. When that is possible, Tuple is just a type like any other in the system (but we need variadics to ex

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

> On Nov 20, 2017, at 6:06 PM, Paul Cantrell wrote: >> >> I think you’re missing the idea here: the idea isn’t to provide exactly >> syntax mapping of Ruby (or Python) into Swift, it is to expose the >> underlying semantic concepts in terms of Swift’s syntax. In the case of >> Python, there i

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

IMO, “target environment” and “simulator” are clear and self-explanatory; “destination” means nothing to me, and just because Xcode uses it in the context of a GUI does not mean that it is the best solution. I’m very much in favor of this proposal exactly as it is. On Mon, Nov 20, 2017 at 20:50 Be

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

Ignoring synthesized conformances for a second, think about how you would manually implement a conformance of a tuple type to a protocol. You would need some way to statically “iterate” over all the component types of the tuple — in fact this is the same as having variadic generics. If we had v

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

> On Nov 15, 2017, at 10:00 PM, Brent Royal-Gordon > wrote: >> On Nov 14, 2017, at 11:29 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> extension PyVal { >> subscript(dynamicMember member: String) -> PyVal { >> get { >> let result = PyObject

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

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 existing synthesis to handle structs/enums when a field/payload has a tuple of things that are Equatable/Hashable, and in that PR it was (rightly) observed, as

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

> On Nov 20, 2017, at 7:47 PM, Chris Lattner via swift-evolution > wrote: > >> On Nov 20, 2017, at 1:41 PM, David Waite >> wrote: >> >> In ruby, parens are optional. So, >> >> v = foo.value >> >> and >> >> v = foo.value() >> >> are identical. > > Ok, I wasn’t aware of that. It isn’t cl

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

Agree: I think it’s painfully obvious that we want tuples to conform to Equatable under the appropriate circumstances. Whether this is magic or not is not strictly settled (though I agree with Kelvin that magic is sensible here), but right now the issue is that tuples can’t conform to protocols at

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

> On Nov 15, 2017, at 9:23 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> On Nov 15, 2017, at 8:35 PM, Paul Cantrell via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Q: Is there any special handling for that member name string — to handle >> ruby method names

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

On Nov 15, 2017, at 8:35 PM, Paul Cantrell via swift-evolution wrote: > Interesting! I like the spirit of this proposal a lot. > > One question: presumably this behaves like Ruby’s method_missing in that any > natively implemented members shadow the dynamic ones? i.e. Swift looks for a > stati

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

On Nov 20, 2017, at 5:48 PM, Kelvin Ma wrote: > the end goal here is to use tuples as a compatible currency type, to that end > it makes sense for these three protocols to be handled as “compiler magic” > and to disallow users from manually defining tuple conformances themselves. > i’m not a fa

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

> On 21 Nov 2017, at 00:17, Jonathan Hull wrote: > > I would also like to see something shorter than targetEnvironment(), but it > is somewhat infrequently used, so it isn’t that big a deal. It is just > compared to os() and arch(), this is kind of a beast. It is a power user > thing, so mayb

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 12:50 PM, David Hart via swift-evolution > wrote: > > > >> On 20 Nov 2017, at 21:10, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Nov 20, 2017, at 10:50 AM, Slava Pestov via swift-evolution >>> mailto:swift-evolution@swi

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

the end goal here is to use tuples as a compatible currency type, to that end it makes sense for these three protocols to be handled as “compiler magic” and to disallow users from manually defining tuple conformances themselves. i’m not a fan of compiler magic, but Equatable, Hashable, and Comparab

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 1:41 PM, David Waite wrote: > > In ruby, parens are optional. So, > > v = foo.value > > and > > v = foo.value() > > are identical. Ok, I wasn’t aware of that. It isn’t clear that we’d want to carry that into a “Ruby APIs when used in Swift” though! One could definit

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

> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution > wrote: > > when SE-185 > > went through swift evolution, it was agreed that the next logical step >

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

when SE-185 went through swift evolution, it was agreed that the next logical step is synthesizing these conformances for tup

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

> On Nov 16, 2017, at 2:23 PM, Ted Kremenek via swift-evolution > wrote: > > When reviewing a proposal, here are some questions to consider: > > What is your evaluation of the proposal? > I think the functionality is good, but I would like to see some thought on what future values could be t

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

> On Nov 20, 2017, at 1:58 PM, Drew Crawford via swift-evolution > wrote: > > I'm "weak oppose" on this proposal. > > The core premise here is to increase the encapsulation of a struct around its > member variables. But I think the purview of encapsulation is more classes > than structs.

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

I agree that filterMap is just as confusing and awkward as flatMap, if not more. Filter works on Bools, not nils. It is just asking for trouble/confusion, and I would hate to rename this again next year. If the word ‘filter’ must be used, then I recommend using ‘filteringMap()’ to lessen con

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

> On 17 Nov 2017, at 9:23 am, Ted Kremenek via swift-evolution > wrote: > > The review of "SE-0190 - Target environment platform condition" begins now > and runs through November 24, 2017. > > The proposal is available here: > > https://github.com/apple/swift-evolution/blob/master/proposals

Re: [swift-evolution] [Review] SE-0190: Target environment platform condition

Since there's been no on-list discussion, I'd like to mention that I think this is a nifty idea. Being able to easily isolate code for device-only environments has been a consistent win for me. -- E > On Nov 16, 2017, at 3:23 PM, Ted Kremenek via swift-evolution > wrote: > > The review of "S

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

On Nov 20, 2017, at 1:31 PM, John McCall via swift-evolution wrote: > >> On Nov 20, 2017, at 12:22 PM, BJ Homer > > wrote: >>> On Nov 20, 2017, at 10:09 AM, Drew Crawford via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> The typical case for th

Re: [swift-evolution] Python Interop with Swift 4+

In ruby, parens are optional. So, v = foo.value and v = foo.value() are identical. There dot syntax is only used for method invocation, so there is no external access to instance variables without some twiddling; similarly getting access to a Proc/lambda/Method requires twiddling in Ruby (alt

Re: [swift-evolution] Python Interop with Swift 4+

> On 20 Nov 2017, at 21:10, Chris Lattner via swift-evolution > wrote: > > >> On Nov 20, 2017, at 10:50 AM, Slava Pestov via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >>> On Nov 20, 2017, at 1:39 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution

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

This is why I really like compact/compactMap. > On Nov 20, 2017, at 3:31 PM, John McCall via swift-evolution > wrote: > >> On Nov 20, 2017, at 12:22 PM, BJ Homer > > wrote: >>> On Nov 20, 2017, at 10:09 AM, Drew Crawford via swift-evolution >>> mailto:swift-evolution@

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

> On Nov 20, 2017, at 12:22 PM, BJ Homer wrote: >> On Nov 20, 2017, at 10:09 AM, Drew Crawford via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> The typical case for this function in my code is the identity closure, that >> is >> >> let a: [Int?] = ... >> print(a.f

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 10:50 AM, Slava Pestov via swift-evolution > wrote: > > > >> On Nov 20, 2017, at 1:39 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> It is straight-forward (and fits very very naturally into the Swift call >> model) to support

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0189: Restrict Cross-module Struct Initializers

I'm "weak oppose" on this proposal. The core premise here is to increase the encapsulation of a struct around its member variables.  But I think the purview of encapsulation is more classes than structs.  e.g. a struct leaks information about the mutation of its member variables, even if those

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 1:39 PM, Chris Lattner via swift-evolution > wrote: > > It is straight-forward (and fits very very naturally into the Swift call > model) to support the second one as an atomic thing, which is I think what > you’re getting at. What if you write ‘let fn = obj.method’?

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 12:16 AM, David Hart via swift-evolution > wrote: > I’ve had a quick look into how your proposals will allow interop with other > dynamic languages. It seems that the model that you chose, where calling a > function is a two-step process (getting a DynamicCallable function

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

> On Nov 20, 2017, at 10:09 AM, Drew Crawford via swift-evolution > wrote: > > The typical case for this function in my code is the identity closure, that is > > let a: [Int?] = ... > print(a.filterMap {$0}) > > filterMap is quite poor for this situation because *each* component in t

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

The typical case for this function in my code is the identity closure, that is     let a: [Int?] = ...     print(a.filterMap {$0}) filterMap is quite poor for this situation because *each* component in the term is inaccurate: 1.  While we are filtering in the "english sense", in Swift the word

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 7:08 AM, David Hart via swift-evolution > wrote: > > > >> On 20 Nov 2017, at 12:34, Brent Royal-Gordon > > wrote: >> >>> On Nov 20, 2017, at 12:32 AM, David Waite via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>>

Re: [swift-evolution] proposal 0143-conditional-conformances

Thanks for the links. This news makes my week. -Matt On Nov 20, 2017, at 00:16, Brent Royal-Gordon wrote: >> On Nov 19, 2017, at 4:11 PM, Matt Whiteside via swift-evolution >> wrote: >> >> Bosses at Apple: if you are reading this, please allow the swift compiler >> team the bandwidth to wo

Re: [swift-evolution] Python Interop with Swift 4+

> On 20 Nov 2017, at 12:34, Brent Royal-Gordon wrote: > >> On Nov 20, 2017, at 12:32 AM, David Waite via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Nov 20, 2017, at 1:16 AM, David Hart via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >> >>

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 12:32 AM, David Waite via swift-evolution > wrote: > >> On Nov 20, 2017, at 1:16 AM, David Hart via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> > > >> Moreover, Ruby allows classes to have instance variables with the same name >> as methods: >> >>

Re: [swift-evolution] Python Interop with Swift 4+

> On Nov 20, 2017, at 1:16 AM, David Hart via swift-evolution > wrote: > > Moreover, Ruby allows classes to have instance variables with the same name > as methods: > > class Foo > def initialize() > @bar = 5 > end > > def bar() > puts “Hello" > end > end > > In that case

Re: [swift-evolution] proposal 0143-conditional-conformances

In many software projects in the real world the tests would have been gone not the code... *weeps as that is so true :/“... Sent from my iPhone On 20 Nov 2017, at 08:16, Brent Royal-Gordon via swift-evolution wrote: >> On Nov 19, 2017, at 4:11 PM, Matt Whiteside via swift-evolution >> wrote

Re: [swift-evolution] Python Interop with Swift 4+

For what it’s worth, the Lua Programming language also has a similar C API to Ruby. So it might be worth writing very simple glue code for the most common dynamic languages to see how the DynamicMemberLookupProtocol and DynamicCallable protocols hold up before the proposals are considered for a

Re: [swift-evolution] proposal 0143-conditional-conformances

> On Nov 19, 2017, at 4:11 PM, Matt Whiteside via swift-evolution > wrote: > > Bosses at Apple: if you are reading this, please allow the swift compiler > team the bandwidth to work on this. Thanks. They are. If you take a look at recent pull requests at

Re: [swift-evolution] Python Interop with Swift 4+

Hi Chris, I’ve had a quick look into how your proposals will allow interop with other dynamic languages. It seems that the model that you chose, where calling a function is a two-step process (getting a DynamicCallable function from a DynamicMemberLookupProtocol type) fits Python like a glove,

Re: [swift-evolution] proposal 0143-conditional-conformances

+1 Sent from my iPhone > On 20 Nov 2017, at 00:11, Matt Whiteside via swift-evolution > wrote: > > Just wanted to upvote the conditional conformances proposal. > > I was bummed to find out that I couldn’t do this: > > extension Array:Drawable where Element == CGPoint{} > > Bosses at Apple: