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

2017-11-20 Thread David Waite via swift-evolution 


> 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 where Swift and 
> Python differs (e.g. Python slicing syntax vs Swift ranges).  In my opinion, 
> Swift syntax wins here, we shouldn’t try to ape a non-native syntax in Swift.

Just wanted to point out Ruby language rules. For swift, you’d probably want to 
have property-style accessors always return something akin to a function 
pointer.


> 
>> More difficult would be the use of ‘=‘, ‘!’, and ‘?’ - all legal in Ruby 
>> method names as suffixes.
> 
> Using those would require backquotes:
> 
> x.`what?`() 

Ruby attributes syntax does wind up looking a bit ugly there. For `bar` on 
class `Foo` in ruby, 

x.foo() # return value of attribute foo
x.`foo=`(5) # assign value of foo as 5

Not pretty, but it should work. All the approaches I’ve been thinking up to 
improve that wind up being pretty nonintuitive and fragile.


-DW
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
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 use-case which uses read-only dynamic members.
- Minor wording changes.

That said, this is significantly similar to the earlier draft.  I welcome 
suggestions for improvements to the proposal, and insight into anything that is 
unclear or insufficiently motivated.

Thanks!

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Kelvin Ma via swift-evolution 
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
> 
> 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 is the time to
> start thinking about this. i’m also tacking on Comparable to the other
> two protocols because there is precedent in the language from SE-15
> 
> that tuple comparison is something that makes sense to write.
>
> EHC conformance is even more important for tuples than it is for structs
> because tuples effectively have no workaround whereas in structs, you could
> just manually implement the conformance. this is especially relevant in
> graphics and scientific contexts where tuples are used to represent color
> values and points in 2D or 3D space. today you still can’t do things like
>
> let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .
>
> the commonly suggested “workaround”, which is to “upgrade” the tuple to a
> struct is problematic for two reasons:
>
> 1. it defeats the purpose of having tuples in the language
>
> 2. tuples are a logical currency type for commonly used types like points
> and vectors. If every library defined its own custom point/vector types we
> would soon (already?) have a nightmare situation where no geometry/graphics
> library would be compatible with any other geometry/graphics library, at
> least not without a lot of annoying, let alone wasteful swizzling and
> manual conversion routines in the main application.
>
>
> Actually I don't think that tuples should be used for points and vectors
> at all, because I prefer to differentiate these two concepts which requires
> nominal types, e.g.
>
> struct Point {
> func distance(to point: Point) -> Vector
> func offsetBy(_ offset: Vector) -> Point
> }
>
> Notwithstanding this disagreement I too think that EHC conformance for
> tuples would be useful.
>
> -Thorsten
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 


> 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 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 
>> express it).
> 
> Eye-opening! Now I understand how important variadic generics are. Somebody 
> should add that example to the Generics Manifesto. Questions:
> 
> • Doesn’t this simplification of the type system hoist Variadic Generics back 
> up the list of priorities?

Not above conditional and recursive conformances.

> • Would it be desirable to implement them before ABI stability to “remove” 
> tuples from the ABI?
> • If not, is the current ABI already flexible enough to support them if they 
> are implemented later on?

I am not the expert on this (Doug Gregor is), but I think we can add it later 
in an ABI additive way.

-Chris





>> Once you have that, then you could write conformances in general, as well as 
>> conditional conformances that depend on (e.g.) all the element types being 
>> equatable.
>> 
>> 
>> We also need that to allow functions conform to protocols, because functions 
>> aren’t "T1->T2” objects, the actual parameter list is an inseparable part of 
>> the function type, and the parameter list needs variadics.
>> 
>> -Chris
>> 
>>> On Nov 20, 2017, at 6:10 PM, Slava Pestov >> > wrote:
>>> 
>>> 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 variadic generics, we could implement tuples conforming to 
>>> protocols, either by refactoring the compiler to allow conforming types to 
>>> be non-nominal, or by reworking things so that a tuple is a nominal type 
>>> with a single variadic generic parameter.
>>> 
>>> Slava
>>> 
 On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
 mailto:swift-evolution@swift.org>> 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 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 Chris just did, that making tuples conform to protocols would 
 be a more general solution that solves the same problem you want to solve 
 here.
 
 I'd love to dig into this more, but last time I experimented with it I got 
 stuck on places where the protocol conformance machinery expects 
 NominalTypeDecls, and I wasn't sure where the right place to hoist that 
 logic up to was (since tuples don't have a corresponding Decl from what I 
 can tell). Any pointers?
 
 On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 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 fan of compiler magic, but Equatable, Hashable, and 
> Comparable are special because they’re the basis for a lot of standard 
> library functionality so i think the benefits of making this a special 
> supported case outweigh the additional language opacity.
 
 I understand your goal, but that compiler magic can’t exist until there is 
 something to hook it into.  Tuples can’t conform to protocols right now, 
 so there is nothing that can be synthesized.
 
 -Chris
 
 
> 
> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner  > wrote:
> 
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 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 is the 
>> time to start thinking about this. i’m also tacking on Comp

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

2017-11-20 Thread David Hart via swift-evolution 


> 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 possible, Tuple 
> is just a type like any other in the system (but we need variadics to express 
> it).

Eye-opening! Now I understand how important variadic generics are. Somebody 
should add that example to the Generics Manifesto. Questions:

• Doesn’t this simplification of the type system hoist Variadic Generics back 
up the list of priorities?
• Would it be desirable to implement them before ABI stability to “remove” 
tuples from the ABI?
• If not, is the current ABI already flexible enough to support them if they 
are implemented later on?

> Once you have that, then you could write conformances in general, as well as 
> conditional conformances that depend on (e.g.) all the element types being 
> equatable.
> 
> 
> We also need that to allow functions conform to protocols, because functions 
> aren’t "T1->T2” objects, the actual parameter list is an inseparable part of 
> the function type, and the parameter list needs variadics.
> 
> -Chris
> 
>> On Nov 20, 2017, at 6:10 PM, Slava Pestov  wrote:
>> 
>> 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 variadic generics, we could implement tuples conforming to 
>> protocols, either by refactoring the compiler to allow conforming types to 
>> be non-nominal, or by reworking things so that a tuple is a nominal type 
>> with a single variadic generic parameter.
>> 
>> Slava
>> 
>>> On Nov 20, 2017, at 9:06 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 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 Chris just did, that making tuples conform to protocols would 
>>> be a more general solution that solves the same problem you want to solve 
>>> here.
>>> 
>>> I'd love to dig into this more, but last time I experimented with it I got 
>>> stuck on places where the protocol conformance machinery expects 
>>> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
>>> logic up to was (since tuples don't have a corresponding Decl from what I 
>>> can tell). Any pointers?
>>> 
 On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
  wrote:
> 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 fan of compiler magic, but Equatable, Hashable, and 
> Comparable are special because they’re the basis for a lot of standard 
> library functionality so i think the benefits of making this a special 
> supported case outweigh the additional language opacity.
 
 I understand your goal, but that compiler magic can’t exist until there is 
 something to hook it into.  Tuples can’t conform to protocols right now, 
 so there is nothing that can be synthesized.
 
 -Chris
 
 
> 
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner  
>> wrote:
>> 
>>> 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 is synthesizing these conformances for tuple types, though 
>>> it was left out of the original proposal to avoid mission creep. I 
>>> think now is the time to start thinking about this. i’m also tacking on 
>>> Comparable to the other two protocols because there is precedent in the 
>>> language from SE-15 that tuple comparison is something that makes sense 
>>> to write.
>>> 
>>> EHC conformance is even more important for tuples than it is for 
>>> structs because tuples effectively have no workaround whereas in 
>>> structs, you could just manually implement the conformance. 
>> 
>> In my opinion, you’re approaching this from the wrong direction.  The 
>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>> they could, synthesizing these conformances would be straight-forward.
>> 
>> If you’re interested in pushing this forward, the discussion is “how do 
>> non-nominal types

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

2017-11-20 Thread Thorsten Seitz via swift-evolution 


> 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 is the time 
> to start thinking about this. i’m also tacking on Comparable to the other two 
> protocols because there is precedent in the language from SE-15 that tuple 
> comparison is something that makes sense to write.
> 
> EHC conformance is even more important for tuples than it is for structs 
> because tuples effectively have no workaround whereas in structs, you could 
> just manually implement the conformance. this is especially relevant in 
> graphics and scientific contexts where tuples are used to represent color 
> values and points in 2D or 3D space. today you still can’t do things like 
> 
> let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .
> 
> the commonly suggested “workaround”, which is to “upgrade” the tuple to a 
> struct is problematic for two reasons:
> 
> 1. it defeats the purpose of having tuples in the language
> 
> 2. tuples are a logical currency type for commonly used types like points and 
> vectors. If every library defined its own custom point/vector types we would 
> soon (already?) have a nightmare situation where no geometry/graphics library 
> would be compatible with any other geometry/graphics library, at least not 
> without a lot of annoying, let alone wasteful swizzling and manual conversion 
> routines in the main application.

Actually I don't think that tuples should be used for points and vectors at 
all, because I prefer to differentiate these two concepts which requires 
nominal types, e.g.

struct Point {
func distance(to point: Point) -> Vector
func offsetBy(_ offset: Vector) -> Point
}

Notwithstanding this disagreement I too think that EHC conformance for tuples 
would be useful. 

-Thorsten


> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 


> 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 incorporated a bunch of feedback from the first round of discussion:
> 
> - I’ve significantly increased the motivation section, talking about the 
> value of solving this problem, and explaining why IMO an “ObjC Importer” 
> approach is a bad idea.
> - I’ve made it possible for (e.g.) a Javascript client to implement support 
> for this while statically rejecting keyword arguments, but allow (e.g.) a 
> Python implementation to accept them.
> - I’ve expanded the model to support the name lookup requirements of Ruby and 
> other smalltalk’y languages that require a base name + argument labels be 
> present to resolve calls.
> - I’ve expanded the alternatives section to explain why statically resolvable 
> callables are orthogonal to this proposal and already pretty well served by 
> Swift today.
> - I’ve expanded the alternatives section to talk about F# type providers, 
> explaining why they don’t solve this problem and are an interesting follow-on 
> refinement to consider after taking this proposal (or something like it).
> 
> That said, there is at least one specific obviously bad thing about this 
> proposal: the name “DynamicCallableWithKeywordsToo” which I appreciate help 
> on.
> 
> If you’re interested in this topic, I’d really appreciate it if you’d read 
> the new draft of the proposal.  It is significantly different than the 
> original draft.  I welcome suggestions for improvements to the proposal, and 
> insight into anything that is unclear or insufficiently motivated.
> 
> Thanks!
> 
> -Chris
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
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 getters and setters, while 
>>> the method subscript could return a ready-to-call `Method` object.
>> 
>> 
>> Better yet, why bother with the ready-to-call Method-like object? Just call 
>> it! A Ruby binding with separate property and method handling would then 
>> look like this:
>> 
>> extension RubyObj: DynamicMemberLookupProtocol {
>>   func callDynamicMethod(dynamicMethod method: String, args: 
>> [RubyObject]) -> RubyObj {
>> get {
>>   return RubyObject_send(rubyObject, method: member, args: args)
>> }
>>   }
>>   
>>   subscript(dynamicMember member: String) -> RubyObj {
>> get {
>>   return RubyObject_send(rubyObject, method: member, args: [])
>> }
>> set {
>>   RubyObject_send(rubyObject, method: "\(member)=", args: [newValue])
>> }
>>   }
>> }
>> 
>> When Swift sees myObj.name, it uses the getter subscript. When Swift sees 
>> myObj.name(), it uses the method invocation. Both work in Swift just as they 
>> do in Ruby — and more importantly, Ruby APIs wouldn’t feel so very awkward 
>> when used from Swift.
> 
> Right, that should work directly!
> 

I just sent out draft 2 of the DynamicCallable proposal, which directly 
includes support for this.  Thanks for the discussion and insight!

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
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 about the value 
of solving this problem, and explaining why IMO an “ObjC Importer” approach is 
a bad idea.
- I’ve made it possible for (e.g.) a Javascript client to implement support for 
this while statically rejecting keyword arguments, but allow (e.g.) a Python 
implementation to accept them.
- I’ve expanded the model to support the name lookup requirements of Ruby and 
other smalltalk’y languages that require a base name + argument labels be 
present to resolve calls.
- I’ve expanded the alternatives section to explain why statically resolvable 
callables are orthogonal to this proposal and already pretty well served by 
Swift today.
- I’ve expanded the alternatives section to talk about F# type providers, 
explaining why they don’t solve this problem and are an interesting follow-on 
refinement to consider after taking this proposal (or something like it).

That said, there is at least one specific obviously bad thing about this 
proposal: the name “DynamicCallableWithKeywordsToo” which I appreciate help on.

If you’re interested in this topic, I’d really appreciate it if you’d read the 
new draft of the proposal.  It is significantly different than the original 
draft.  I welcome suggestions for improvements to the proposal, and insight 
into anything that is unclear or insufficiently motivated.

Thanks!

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Thorsten Seitz via swift-evolution 


> 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 “capturing” before it.

+1 including the keyword "capturing"

-Thorsten

> 
>> I think #4 is ambiguous with array literals unfortunately.
>> 
>> Perhaps this proposal should be split in two — the ‘self.’/escaping part is 
>> source breaking, and will likely require more discussion. Adding capture 
>> lists to local functions seems like a more straightforward change.
> 
> +1.
> 
> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Thorsten Seitz via swift-evolution 
+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, 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 the 
 term is inaccurate:
>>> 
>>> filterMap is indeed an awkward name for this use case, just like flatMap 
>>> is. In my experience, about half of my use cases use the identity closure, 
>>> and half actually make use of the closure in a meaningful way. I would 
>>> support a proposal to add something like Sequence.dropNils (actual name to 
>>> be determined), and then we could let this proposal target the 
>>> non-identity-closure use case.
>> 
>> If the identity closure (i.e. "please remove the nils from this sequence") 
>> is a common use case, then I absolutely agree that we should consider adding 
>> a specific operation for that, and that name might illuminate the right name 
>> for the mapping version.
>> 
>> John.
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
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.  Recall that this protocol is compiler 
>> “magic” that is part of an implementation of a type, it isn’t really part of 
>> the user-exposed API of the type.  I wouldn’t expect a user to ever write:
>> 
>>pyVal[dynamicMember: “foo”]
>> 
>> Even though they could.
> 
> I'm not sure why you say it's not part of the user-exposed API. The type 
> conforms to the protocol, and the protocol has this subscript, and there is 
> nothing preventing someone from using it.

Yes, I understand that of course.

> And if for some reason you have the name of the member in a string variable 
> and want to use it, you *have to* use it to get to the variable. So it'll 
> definitely get used.

Not necessarily.  Nothing prevents a *specific* client from implementing a 
better accessor for their specific use, and I’d strongly encourage them to do 
so.  This is a compiler hook - just like ExpressibleByArrayLiteral exposes an 
ArrayLiteralElement associated type and init(arrayLiteral:..) initializer… even 
on Set! 

I have definitely seen user code using these, but that isn’t the intention.  
The best solution to this is either to prevent them from being exported as API 
(my suggestion of something something like a “private conformance” 
implementation detail thing) or by simply marking these members with an 
attribute, so they don’t show up in code completion.

I do care about this sort of thing getting fixed, and I personally prefer the 
attribute+code completion change, but this is an existing problem in swift, 
orthogonal from this proposal.  If you’d like to see if fixed, then by all 
means, please bring this up and fix it.  It is more offensive that Int gets 
weird members like IntegerLiteralType and an integerLiteral initializer 
[[[which show up all the time…. :-( :-(   ]]] than the specific impact this 
proposal will have on a small set of narrow types people hardly interact with.

> Perhaps supplemental isn't the right word, but I wanted to convey that it 
> supplements the Swift-defined methods and does not shadow them. For instance, 
> in your PyVal protocol type there's a member `ownedPyObject` that won't be 
> accessible with `dynamicMember` but will be dispatched through the protocol 
> witness table.

Yes, I understand what you’re saying, but specific naming does matter.  I don’t 
think that ownedPyObject is in huge danger of conflicting with something that 
matters, but if it were, I’d suggest name mangling it to something even less 
likely to conflict, and I’d mark ownedPyObject with the same attribute to hide 
it from code completion, so people don’t see it every time they code complete 
on a PyVal.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Slava Pestov via swift-evolution 


> 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 the type is subsequently mutated (which important clients do not do).  
> This amortizes the cost of the sort across many calls to the accessor.

Sure, but it’s hard to completely encapsulate this kind of caching behavior 
inside the type. For example, thread safety. But yes, there are different 
tradeoffs with reference and value types, and it’s hard to argue that one is 
better for encapsulation than the other.

> > We want to be able to add new stored properties to structs, or change 
> > existing stored properties to computed properties (and vice versa) without 
> > breaking binary or source compatibility.
> 
> If CGAffineTransform, CGPoint, in_addr_t etc. are changing their members we 
> have a problem.  There are probably structs where this makes more sense, but 
> I can't immediately think of an example.

in_addr_t is actually mostly opaque so it’s actually not a good example.I agree 
that CGAffineTransform and such are trivial. But it’s easy to think of cases 
where you want to change the internal representation of a data type without 
changing it’s API, and sometimes this means stored properties become computed 
properties. The only place in the language where the difference between stored 
and computed properties can be observed is inside a non-delegating initializer 
of a struct, so it makes sense to prohibit them from being defined outside of 
the original module.

Slava

> 
> 
> On November 20, 2017 at 6:16:55 PM, Slava Pestov (spes...@apple.com 
> ) wrote:
> 
>> 
>> 
>>> On Nov 20, 2017, at 1:58 PM, Drew Crawford via swift-evolution 
>>> mailto:swift-evolution@swift.org>> 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.
>> 
>> 
>> How so? It seems that encapsulation is orthogonal to reference/value 
>> semantics.
>> 
>>>  e.g. a struct leaks information about the mutation of its member 
>>> variables, even if those variables are private.
>> 
>> Can you explain what you mean by this?
>> 
>>>  Structs are the obvious implementation for a named tuple (CGPoint 
>>> CGAffineTransform UIColor etc.) where there is inherently a fixed set of 
>>> members that are more conveniently accessed directly.  Structs and classes 
>>> have different purposes and so the argument for consistency with classes is 
>>> weak.
>>> 
>>> With regard to the BalancedPair problem, I would prefer to see a "final 
>>> struct" or "required init”.
>> 
>> The real reason we want to introduce this language change is to solve some 
>> problems related to resilience. We want to be able to add new stored 
>> properties to structs, or change existing stored properties to computed 
>> properties (and vice versa) without breaking binary or source compatibility. 
>> Since non-delegating initializers expose the exact set of stored properties 
>> to the client module, they break the encapsulation that we need to allow 
>> this.
>> 
>> Slava
>>> On November 14, 2017 at 1:31:25 PM, Ted Kremenek (kreme...@apple.com 
>>> ) wrote:
>>> 
 The review of "SE-0189: Restrict Cross-module Struct Initializers" begins 
 now and runs through November 21, 2017.
 
 The proposal is available here:
 
 https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
  
 
 Reviews are an important part of the Swift evolution process. All review 
 feedback should be sent to the swift-evolution mailing list at:
 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
 or, if you would like to keep your feedback private, directly to the 
 review manager. 
 
 When replying, please try to keep the proposal link at the top of the 
 message:
 
 Proposal link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
  
 
 ...
 Reply text
 ...
 Other replies
 What goes into a review of a proposal?
 
 The goal of the review process is to improve the proposal under review 
 through constructive criticism and, eventually, determine the direction of 
 Swift. 
 
 When reviewing a proposal, here are some questions to

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

2017-11-20 Thread Drew Crawford via swift-evolution 
> 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}
    public var sortedMessages: [String] { return _messages.sorted() }
}

We subsequently discover in the wild that although there are a variety of 
client patterns, certain "important" clients have the particular pattern

1.  Add messages up front
2.  Use sortedMessages accessor frequently and exclusively

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 the 
type is subsequently mutated (which important clients do not do).  This 
amortizes the cost of the sort across many calls to the accessor.

Although the underlying storage is "private" and we may consider its 
sorted-arity an implementation detail of Mailbox, in fact there is no 
straightforward way to get to that implementation from this one.  When we chose 
value semantics we promised clients that our "encapsulated" values will not 
change inside a getter; mutating the "hidden" storage breaks our promise.

I would argue this "encapsulation failure" of the _messages array is actually a 
feature, and part of the draw of value types is that they provide these kinds 
of guarantees to clients, and we subvert them at our peril. In cases where that 
is not desired reference types are available.

> We want to be able to add new stored properties to structs, or change 
> existing stored properties to computed properties (and vice versa) without 
> breaking binary or source compatibility.

If CGAffineTransform, CGPoint, in_addr_t etc. are changing their members we 
have a problem.  There are probably structs where this makes more sense, but I 
can't immediately think of an example.


On November 20, 2017 at 6:16:55 PM, Slava Pestov (spes...@apple.com) wrote:



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.


How so? It seems that encapsulation is orthogonal to reference/value semantics.

 e.g. a struct leaks information about the mutation of its member variables, 
even if those variables are private.

Can you explain what you mean by this?

 Structs are the obvious implementation for a named tuple (CGPoint 
CGAffineTransform UIColor etc.) where there is inherently a fixed set of 
members that are more conveniently accessed directly.  Structs and classes have 
different purposes and so the argument for consistency with classes is weak.

With regard to the BalancedPair problem, I would prefer to see a "final struct" 
or "required init”.

The real reason we want to introduce this language change is to solve some 
problems related to resilience. We want to be able to add new stored properties 
to structs, or change existing stored properties to computed properties (and 
vice versa) without breaking binary or source compatibility. Since 
non-delegating initializers expose the exact set of stored properties to the 
client module, they break the encapsulation that we need to allow this.

Slava
On November 14, 2017 at 1:31:25 PM, Ted Kremenek (kreme...@apple.com) wrote:

The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now 
and runs through November 21, 2017.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
Reviews are an important part of the Swift evolution process. All review 
feedback should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager. 

When replying, please try to keep the proposal link at the top of the message:

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
...
Reply text
...
Other replies
What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. 

When reviewing a proposal, here are some questions to consider:

What is your evaluation of the proposal?

Is the problem being addressed significant enough to warrant a change to Swift?

Does this proposal fit well with the feel and direction of Swift?

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?

How much effort did you put into your review? A glance, a

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

2017-11-20 Thread Michel Fortin via swift-evolution 
> 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 
>> members of the class, whereas in reality you'll only get the ones you have 
>> manually implemented. Even methods and properties having the `dynamic` 
>> attribute won't be available, even though the subscript name would suggest 
>> that.
>> 
>> I would propose adding the word `supplemental`to the subscript name and the 
>> name of the protocol to make it clearer that this is only for adding members 
>> that are not declared in the class (including the `dynamic` ones).
>> 
>> 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.  Recall that this protocol is compiler “magic” 
> that is part of an implementation of a type, it isn’t really part of the 
> user-exposed API of the type.  I wouldn’t expect a user to ever write:
> 
>pyVal[dynamicMember: “foo”]
> 
> Even though they could.

I'm not sure why you say it's not part of the user-exposed API. The type 
conforms to the protocol, and the protocol has this subscript, and there is 
nothing preventing someone from using it. And if for some reason you have the 
name of the member in a string variable and want to use it, you *have to* use 
it to get to the variable. So it'll definitely get used.

Perhaps supplemental isn't the right word, but I wanted to convey that it 
supplements the Swift-defined methods and does not shadow them. For instance, 
in your PyVal protocol type there's a member `ownedPyObject` that won't be 
accessible with `dynamicMember` but will be dispatched through the protocol 
witness table.

> Maybe we need to add private conformances to Swift or something :-)

Maybe, but that's not part of the proposal. :-)

-- 
Michel Fortin
https://michelf.ca

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread 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 “capturing” before it.

> I think #4 is ambiguous with array literals unfortunately.
> 
> Perhaps this proposal should be split in two — the ‘self.’/escaping part is 
> source breaking, and will likely require more discussion. Adding capture 
> lists to local functions seems like a more straightforward change.

+1.

-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 

> 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 is a good idea, but I don't like bringing the already weird use 
> of `in` to actual functions.
> 
> By analogy with the current closure syntax, the capture list ought to go 
> somewhere before the parameter list, in one of these slots:
> 
> 1.func fn[foo, bar](param: T) throws -> T where T: Equatable { … }
> 2.func fn[foo, bar](param: T) throws -> T where T: Equatable { … }
> 3.func [foo, bar] fn(param: T) throws -> T where T: Equatable { … }
> 4.[foo, bar] func fn(param: T) throws -> T where T: Equatable { … }
> 
> Of these options, I actually think #4 reads best; 1 and 2 are very cluttered, 
> and 3 just seems weird. But it seems like the one that would be easiest to 
> misparse.

This is relatively rare, so I’d suggest introducing a context sensitive keyword 
to make it explicit, perhaps:

5. func fn[foo, bar](param: T) throws -> T where T: Equatable captures [foo, 
bar] { … }

It makes sense (IMO) to keep it near the body of the function, since it is more 
an artifact of the implementation than it is about the API.  Yes I know that 
caring about the API of a local function is weird :-)  


-Chris

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
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, 
> with the ability to coerce Function -> ThrowingFunction? (Async might pose 
> similar issues?)

Right, there are several ways we could express that which would have to be 
designed.  There are other questions as well: e.g. how do we represent inout?

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
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 that Y 
> will probably not be a thing for the forseeable future and we really need X 
> right now

Sure, you can generate implementations of == or hashing functions, but that 
won’t let you use them as the key to a dictionary.  For that, you need actual 
conformance.

-Chris


> 
> On Mon, Nov 20, 2017 at 9:10 PM, Slava Pestov via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 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 variadic generics, we could implement tuples conforming to 
> protocols, either by refactoring the compiler to allow conforming types to be 
> non-nominal, or by reworking things so that a tuple is a nominal type with a 
> single variadic generic parameter.
> 
> Slava
> 
> 
>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
>> mailto:swift-evolution@swift.org>> 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 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 Chris just 
>> did, that making tuples conform to protocols would be a more general 
>> solution that solves the same problem you want to solve here.
>> 
>> I'd love to dig into this more, but last time I experimented with it I got 
>> stuck on places where the protocol conformance machinery expects 
>> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
>> logic up to was (since tuples don't have a corresponding Decl from what I 
>> can tell). Any pointers?
>> 
>> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 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 fan of compiler magic, but Equatable, Hashable, and 
>>> Comparable are special because they’re the basis for a lot of standard 
>>> library functionality so i think the benefits of making this a special 
>>> supported case outweigh the additional language opacity.
>> 
>> I understand your goal, but that compiler magic can’t exist until there is 
>> something to hook it into.  Tuples can’t conform to protocols right now, so 
>> there is nothing that can be synthesized.
>> 
>> -Chris
>> 
>> 
>>> 
>>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner >> > wrote:
>>> 
 On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 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 is the time to 
 start thinking about this. i’m also tacking on Comparable to the other two 
 protocols because there is precedent in the language from SE-15 
 
  that tuple comparison is something that makes sense to write.
 
 EHC conformance is even more important for tuples than it is for structs 
 because tuples effectively have no workaround whereas in structs, you 
 could just manually implement the conformance. 
>>> 
>>> In my opinion, you’re approaching this from the wrong direction.  The 
>>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>>> they could, synthesizing these conformances would be straight-forward.
>>> 
>>> If you’re interested in pushing this forward, the discussion is “how do 
>>> non-nominal types like tuples and functions conform to protocols”?
>>> 
>>> -Chris
>>> 
>>> 
>>> 
>>> 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/

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

2017-11-20 Thread Tony Allevato via swift-evolution 
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 pose similar issues?)


On Mon, Nov 20, 2017 at 6:17 PM Chris Lattner  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 possible,
> Tuple is just a type like any other in the system (but we need variadics to
> express it).
>
> Once you have that, then you could write conformances in general, as well
> as conditional conformances that depend on (e.g.) all the element types
> being equatable.
>
>
> We also need that to allow functions conform to protocols, because
> functions aren’t "T1->T2” objects, the actual parameter list is an
> inseparable part of the function type, and the parameter list needs
> variadics.
>
> -Chris
>
> On Nov 20, 2017, at 6:10 PM, Slava Pestov  wrote:
>
> 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 variadic generics, we could implement tuples conforming to
> protocols, either by refactoring the compiler to allow conforming types to
> be non-nominal, or by reworking things so that a tuple is a nominal type
> with a single variadic generic parameter.
>
> Slava
>
> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> 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
> 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 Chris just did, that making tuples conform to protocols would
> be a more general solution that solves the same problem you want to solve
> here.
>
> I'd love to dig into this more, but last time I experimented with it I got
> stuck on places where the protocol conformance machinery expects
> NominalTypeDecls, and I wasn't sure where the right place to hoist that
> logic up to was (since tuples don't have a corresponding Decl from what I
> can tell). Any pointers?
>
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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 fan of compiler magic, but Equatable, Hashable, and
>> Comparable are special because they’re the basis for a lot of standard
>> library functionality so i think the benefits of making this a special
>> supported case outweigh the additional language opacity.
>>
>>
>> I understand your goal, but that compiler magic can’t exist until there
>> is something to hook it into.  Tuples can’t conform to protocols right now,
>> so there is nothing that can be synthesized.
>>
>> -Chris
>>
>>
>>
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner 
>> wrote:
>>
>>>
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> 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 is the time to
>>> start thinking about this. i’m also tacking on Comparable to the other
>>> two protocols because there is precedent in the language from SE-15
>>> 
>>> that tuple comparison is something that makes sense to write.
>>>
>>> EHC conformance is even more important for tuples than it is for structs
>>> because tuples effectively have no workaround whereas in structs, you could
>>> just manually implement the conformance.
>>>
>>>
>>> In my opinion, you’re approaching this from the wrong direction.  The
>>> fundamental problem here is that tuples can’t conform to a protocol.  If
>>> they could, synthesizing these conformances would be straight-forward.
>>>
>>> If you’re interested in pushing this forward, the discussion is “how do
>>> non-nominal types like tuple

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

2017-11-20 Thread Kelvin Ma via swift-evolution 
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 need
X right now

On Mon, Nov 20, 2017 at 9:10 PM, Slava Pestov via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 variadic generics, we could implement tuples conforming to
> protocols, either by refactoring the compiler to allow conforming types to
> be non-nominal, or by reworking things so that a tuple is a nominal type
> with a single variadic generic parameter.
>
> Slava
>
>
> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution <
> swift-evolution@swift.org> 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
> 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 Chris just did, that making tuples conform to protocols would
> be a more general solution that solves the same problem you want to solve
> here.
>
> I'd love to dig into this more, but last time I experimented with it I got
> stuck on places where the protocol conformance machinery expects
> NominalTypeDecls, and I wasn't sure where the right place to hoist that
> logic up to was (since tuples don't have a corresponding Decl from what I
> can tell). Any pointers?
>
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> 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 fan of compiler magic, but Equatable, Hashable, and
>> Comparable are special because they’re the basis for a lot of standard
>> library functionality so i think the benefits of making this a special
>> supported case outweigh the additional language opacity.
>>
>>
>> I understand your goal, but that compiler magic can’t exist until there
>> is something to hook it into.  Tuples can’t conform to protocols right now,
>> so there is nothing that can be synthesized.
>>
>> -Chris
>>
>>
>>
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner 
>> wrote:
>>
>>>
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> 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 is the time to
>>> start thinking about this. i’m also tacking on Comparable to the other
>>> two protocols because there is precedent in the language from SE-15
>>> 
>>> that tuple comparison is something that makes sense to write.
>>>
>>> EHC conformance is even more important for tuples than it is for structs
>>> because tuples effectively have no workaround whereas in structs, you could
>>> just manually implement the conformance.
>>>
>>>
>>> In my opinion, you’re approaching this from the wrong direction.  The
>>> fundamental problem here is that tuples can’t conform to a protocol.  If
>>> they could, synthesizing these conformances would be straight-forward.
>>>
>>> If you’re interested in pushing this forward, the discussion is “how do
>>> non-nominal types like tuples and functions conform to protocols”?
>>>
>>> -Chris
>>>
>>>
>>>
>>>
>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swif

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

2017-11-20 Thread Chris Lattner via swift-evolution 

> 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 you have 
> manually implemented. Even methods and properties having the `dynamic` 
> attribute won't be available, even though the subscript name would suggest 
> that.
> 
> I would propose adding the word `supplemental`to the subscript name and the 
> name of the protocol to make it clearer that this is only for adding members 
> that are not declared in the class (including the `dynamic` ones).
> 
> 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.  Recall that this protocol is compiler “magic” 
that is part of an implementation of a type, it isn’t really part of the 
user-exposed API of the type.  I wouldn’t expect a user to ever write:

   pyVal[dynamicMember: “foo”]

Even though they could.  Maybe we need to add private conformances to Swift or 
something :-)

-Chris


> 
> 
>> Le 15 nov. 2017 à 2:29, Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> a écrit :
>> 
>> protocol DynamicMemberLookupProtocol {
>>   associatedtype DynamicMemberLookupValue
>> 
>>   subscript(dynamicMember name: String) -> DynamicMemberLookupValue { get 
>> set }
>> }
>> 
> 
> -- 
> Michel Fortin
> https://michelf.ca 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
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 express it).

Once you have that, then you could write conformances in general, as well as 
conditional conformances that depend on (e.g.) all the element types being 
equatable.


We also need that to allow functions conform to protocols, because functions 
aren’t "T1->T2” objects, the actual parameter list is an inseparable part of 
the function type, and the parameter list needs variadics.

-Chris

> On Nov 20, 2017, at 6:10 PM, Slava Pestov  wrote:
> 
> 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 variadic generics, we could implement tuples conforming to 
> protocols, either by refactoring the compiler to allow conforming types to be 
> non-nominal, or by reworking things so that a tuple is a nominal type with a 
> single variadic generic parameter.
> 
> Slava
> 
>> On Nov 20, 2017, at 9:06 PM, Tony Allevato via swift-evolution 
>> mailto:swift-evolution@swift.org>> 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 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 Chris just 
>> did, that making tuples conform to protocols would be a more general 
>> solution that solves the same problem you want to solve here.
>> 
>> I'd love to dig into this more, but last time I experimented with it I got 
>> stuck on places where the protocol conformance machinery expects 
>> NominalTypeDecls, and I wasn't sure where the right place to hoist that 
>> logic up to was (since tuples don't have a corresponding Decl from what I 
>> can tell). Any pointers?
>> 
>> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 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 fan of compiler magic, but Equatable, Hashable, and 
>>> Comparable are special because they’re the basis for a lot of standard 
>>> library functionality so i think the benefits of making this a special 
>>> supported case outweigh the additional language opacity.
>> 
>> I understand your goal, but that compiler magic can’t exist until there is 
>> something to hook it into.  Tuples can’t conform to protocols right now, so 
>> there is nothing that can be synthesized.
>> 
>> -Chris
>> 
>> 
>>> 
>>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner >> > wrote:
>>> 
 On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 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 is the time to 
 start thinking about this. i’m also tacking on Comparable to the other two 
 protocols because there is precedent in the language from SE-15 
 
  that tuple comparison is something that makes sense to write.
 
 EHC conformance is even more important for tuples than it is for structs 
 because tuples effectively have no workaround whereas in structs, you 
 could just manually implement the conformance. 
>>> 
>>> In my opinion, you’re approaching this from the wrong direction.  The 
>>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>>> they could, synthesizing these conformances would be straight-forward.
>>> 
>>> If you’re interested in pushing this forward, the discussion is “how do 
>>> non-nominal types like tuples and functions conform to protocols”?
>>> 
>>> -Chris
>>> 
>>> 
>>> 
>>> 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org

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

2017-11-20 Thread Chris Lattner via swift-evolution 
> 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 is a lot of direct overlap, but there is also some places 
>> where Swift and Python differs (e.g. Python slicing syntax vs Swift ranges). 
>>  In my opinion, Swift syntax wins here, we shouldn’t try to ape a non-native 
>> syntax in Swift.
>> 
>>> For mapping to Swift, I would say that parens are needed; we can’t guess 
>>> whether a `foo.bar` is meant to be asking for the value of attribute bar or 
>>> a reference to method bar.
>> 
>> +1
> 
> Chris, did you follow at all the earlier chain of emails where Brent, 
> Jean-Daniel and I hashed this out at length? You may not have got to it yet….

Perhaps not, I’m just catching up on this thread now.  Keep in mind I know 
almost nothing about Ruby :-)


> An “always use parens” bridge to Ruby has bad ergonomics
> Zero-arg Ruby methods are a mixture of property-like things that would 
> certainly not use parens in Swift, and function-like things that certainly 
> would:
> 
> // Idiomatic Swift:
> post.author.name.reversed()
> 
> // Swift bridging to Ruby…
> 
> // …if no-args methods •must• use parens:
> post.author().name().reverse()
> 
> // …if no-args methods •can’t• use parens:
> post.author.name.reverse
> 
> If the goal is to make Swift mostly feel like Swift even when bridging to 
> Ruby, then the bridge needs to support both access forms.

Ok, that can certainly be implemented by the two proposals I have in flight.  
No obvious problem there.


> 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 getters and setters, while 
>> the method subscript could return a ready-to-call `Method` object.
> 
> 
> Better yet, why bother with the ready-to-call Method-like object? Just call 
> it! A Ruby binding with separate property and method handling would then look 
> like this:
> 
> extension RubyObj: DynamicMemberLookupProtocol {
>   func callDynamicMethod(dynamicMethod method: String, args: 
> [RubyObject]) -> RubyObj {
> get {
>   return RubyObject_send(rubyObject, method: member, args: args)
> }
>   }
>   
>   subscript(dynamicMember member: String) -> RubyObj {
> get {
>   return RubyObject_send(rubyObject, method: member, args: [])
> }
> set {
>   RubyObject_send(rubyObject, method: "\(member)=", args: [newValue])
> }
>   }
> }
> 
> When Swift sees myObj.name, it uses the getter subscript. When Swift sees 
> myObj.name(), it uses the method invocation. Both work in Swift just as they 
> do in Ruby — and more importantly, Ruby APIs wouldn’t feel so very awkward 
> when used from Swift.

Right, that should work directly!

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Xiaodi Wu via swift-evolution 
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 Ben Rimmington via swift-evolution <
swift-evolution@swift.org> wrote:

> > 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 maybe something like ‘env()’ would work?  I normally try to avoid
> abbreviations, but we have arch() as precedent.  The word ‘Simulator’
> should be what stands out...
>
> Xcode uses `destination`:
>
> e.g. 
>
> e.g. 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Slava Pestov via swift-evolution 
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 variadic generics, we could implement tuples conforming to protocols, 
either by refactoring the compiler to allow conforming types to be non-nominal, 
or by reworking things so that a tuple is a nominal type with a single variadic 
generic parameter.

Slava

> On Nov 20, 2017, at 9:06 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 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 Chris just 
> did, that making tuples conform to protocols would be a more general solution 
> that solves the same problem you want to solve here.
> 
> I'd love to dig into this more, but last time I experimented with it I got 
> stuck on places where the protocol conformance machinery expects 
> NominalTypeDecls, and I wasn't sure where the right place to hoist that logic 
> up to was (since tuples don't have a corresponding Decl from what I can 
> tell). Any pointers?
> 
> On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 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 fan of compiler magic, but Equatable, Hashable, and 
>> Comparable are special because they’re the basis for a lot of standard 
>> library functionality so i think the benefits of making this a special 
>> supported case outweigh the additional language opacity.
> 
> I understand your goal, but that compiler magic can’t exist until there is 
> something to hook it into.  Tuples can’t conform to protocols right now, so 
> there is nothing that can be synthesized.
> 
> -Chris
> 
> 
>> 
>> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner > > wrote:
>> 
>>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 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 is the time to 
>>> start thinking about this. i’m also tacking on Comparable to the other two 
>>> protocols because there is precedent in the language from SE-15 
>>> 
>>>  that tuple comparison is something that makes sense to write.
>>> 
>>> EHC conformance is even more important for tuples than it is for structs 
>>> because tuples effectively have no workaround whereas in structs, you could 
>>> just manually implement the conformance. 
>> 
>> In my opinion, you’re approaching this from the wrong direction.  The 
>> fundamental problem here is that tuples can’t conform to a protocol.  If 
>> they could, synthesizing these conformances would be straight-forward.
>> 
>> If you’re interested in pushing this forward, the discussion is “how do 
>> non-nominal types like tuples and functions conform to protocols”?
>> 
>> -Chris
>> 
>> 
>> 
>> 
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
> 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_GetAttrString(borrowedPyObject, member)!
>>   return PyRef(owned: result)  // PyObject_GetAttrString returns +1 
>> result.
>> }
>> set {
>>   PyObject_SetAttrString(borrowedPyObject, member,
>>  newValue.toPython().borrowedPyObject)
>> }
>>   }
>> }
> 
> This looks great for Python, but let's talk about some other languages for a 
> moment.
> 
> * Ruby and Perl don't have the "call a method by fetching a closure property 
> and invoking it" behavior you're relying on here. Instead, Ruby has a syntax 
> for settable "overloads" of methods (i.e. you can write `def someMember` and 
> `def someMember= (newValue)`), while Perl supports lvalue methods (but 
> sometimes uses getter and setter method pairs instead). How do you envision 
> these behaviors being bridged to Swift? I worry that this protocol may not be 
> sufficient, and that we may need a design which can distinguish between 
> looking up methods and looking up properties.

I’m not sure without more description, but it seems like these are both general 
property models which can be implemented with this protocol as is.  The getter 
would call someMember, and the setter would call someMember=.  What 
complication are you anticipating?


> * Ruby looks up members using symbols, which essentially play the same role 
> as selectors in Objective-C—they're uniqued strings which are used for fast 
> member dispatch. In some cases, you might see non-negligible speed 
> improvements by only looking up the symbol once. Is there a way this design 
> could accommodate that? 

Yes, I think that this is very much in scope for the DynamicCallable proposal.  
We talked about this in the context of Squeak (another smalltalky language), 
and it fits naturally with the design.  I’ll add that when I have time to 
revise the pitch.

> * Generally, you've talked about properties (in this proposal) and methods 
> (in the `DynamicCallable` proposal), but what about subscripts? Obviously you 
> can just specify a `subscript(Pythonable) -> PyVal` on `PyVal` for the simple 
> case, but what if the subscript takes multiple indices or has labels? Do we 
> need a `DynamicSubscriptable` protocol?

Subscripts can already be varargs, so the only reason we’d need a 
DynamicSubscriptable proposal is if there were another language that allowed 
keywords on subscript indices.  If so, then yes, we’d need that.

> * Let's step away from bridging entirely and just think about Swift for a 
> moment.  There are cases where we'd like to make *semi*-dynamic proxies which 
> wrap another type and allow operations based on what's statically known about 
> that type. Think, for example, of the appearance proxy in UIKit: This is an 
> object attached to UIView subclasses which lets you (in essence) set default 
> values for all instances. We currently just pretend it's an instance of 
> `Self`, which mostly works because of Objective-C, but a Swift-native version 
> would probably prefer to return a `UIAppearance` object which used its 
> knowledge of `Self` to expose `Self`'s properties on itself. Is there a way 
> we could design this feature, or a related feature, to cover that kind of use 
> case? That is, to allow a limited set of keys—perhaps even key-path-based 
> when you want static control—with a different type for each key, *or* to 
> allow any key with some common type, depending on your type's needs?

I wouldn’t be at all surprised if this was possible, but given that this type 
erases everything that goes through the proxy, and given that it doesn’t 
provide type checking, it isn’t clear to me that you’d get a really great 
answer.

> * Actually, for that matter, let's talk about key paths. In principle, you 
> can already think of member lookup in Swift—or at least property and 
> subscript lookup—as though it always worked by constructing a key path and 
> using `subscript(keyPath:)` to access it. Is there some way we could model 
> this feature as extending the set of keys available on a given type—perhaps 
> in a way that allowed compile-time-limited and strongly-typed sets of keys, 
> like I mention with the `UIAppearance` example, in addition to the 
> open-ended, type-erased sets you need—and then looking things up by key path? 
> (Sorry if this is a little vague—I know very little about how key paths are 
> implemented.)

I don’t know.

> * An implementation-level question about Swift: Internally, the compiler 
> seems to be moving towards thinking of parameter labels as part of the 
> identifier, rather than having them label the individual arguments. How do 
> you see that jibing with what you're proposing here?

This is part of th

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

2017-11-20 Thread Tony Allevato via swift-evolution 
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 Chris just did, that making tuples conform to protocols would
be a more general solution that solves the same problem you want to solve
here.

I'd love to dig into this more, but last time I experimented with it I got
stuck on places where the protocol conformance machinery expects
NominalTypeDecls, and I wasn't sure where the right place to hoist that
logic up to was (since tuples don't have a corresponding Decl from what I
can tell). Any pointers?

On Mon, Nov 20, 2017 at 5:51 PM Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 fan of compiler magic, but Equatable, Hashable, and
> Comparable are special because they’re the basis for a lot of standard
> library functionality so i think the benefits of making this a special
> supported case outweigh the additional language opacity.
>
>
> I understand your goal, but that compiler magic can’t exist until there is
> something to hook it into.  Tuples can’t conform to protocols right now, so
> there is nothing that can be synthesized.
>
> -Chris
>
>
>
> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner 
> wrote:
>
>>
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> 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 is the time to
>> start thinking about this. i’m also tacking on Comparable to the other
>> two protocols because there is precedent in the language from SE-15
>> 
>> that tuple comparison is something that makes sense to write.
>>
>> EHC conformance is even more important for tuples than it is for structs
>> because tuples effectively have no workaround whereas in structs, you could
>> just manually implement the conformance.
>>
>>
>> In my opinion, you’re approaching this from the wrong direction.  The
>> fundamental problem here is that tuples can’t conform to a protocol.  If
>> they could, synthesizing these conformances would be straight-forward.
>>
>> If you’re interested in pushing this forward, the discussion is “how do
>> non-nominal types like tuples and functions conform to protocols”?
>>
>> -Chris
>>
>>
>>
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Paul Cantrell via swift-evolution 

> 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 clear that we’d want to carry that into 
> a “Ruby APIs when used in Swift” though!  One could definitely argue against 
> the former calling a method, even if that is possible in Ruby APIs.
> 
>> 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 (although there 
>> are shortcuts in normal use, like Symbol#to_proc)
> 
> 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 where Swift and 
> Python differs (e.g. Python slicing syntax vs Swift ranges).  In my opinion, 
> Swift syntax wins here, we shouldn’t try to ape a non-native syntax in Swift.
> 
>> For mapping to Swift, I would say that parens are needed; we can’t guess 
>> whether a `foo.bar` is meant to be asking for the value of attribute bar or 
>> a reference to method bar.
> 
> +1

Chris, did you follow at all the earlier chain of emails where Brent, 
Jean-Daniel and I hashed this out at length? You may not have got to it yet….

Key excerpts:

–

An “always use parens” bridge to Ruby has bad ergonomics
Zero-arg Ruby methods are a mixture of property-like things that would 
certainly not use parens in Swift, and function-like things that certainly 
would:

// Idiomatic Swift:
post.author.name.reversed()

// Swift bridging to Ruby…

// …if no-args methods •must• use parens:
post.author().name().reverse()

// …if no-args methods •can’t• use parens:
post.author.name.reverse

If the goal is to make Swift mostly feel like Swift even when bridging to Ruby, 
then the bridge needs to support both access forms.

–

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 getters and setters, while 
> the method subscript could return a ready-to-call `Method` object.


Better yet, why bother with the ready-to-call Method-like object? Just call it! 
A Ruby binding with separate property and method handling would then look like 
this:

extension RubyObj: DynamicMemberLookupProtocol {
  func callDynamicMethod(dynamicMethod method: String, args: [RubyObject]) 
-> RubyObj {
get {
  return RubyObject_send(rubyObject, method: member, args: args)
}
  }
  
  subscript(dynamicMember member: String) -> RubyObj {
get {
  return RubyObject_send(rubyObject, method: member, args: [])
}
set {
  RubyObject_send(rubyObject, method: "\(member)=", args: [newValue])
}
  }
}

When Swift sees myObj.name, it uses the getter subscript. When Swift sees 
myObj.name(), it uses the method invocation. Both work in Swift just as they do 
in Ruby — and more importantly, Ruby APIs wouldn’t feel so very awkward when 
used from Swift.


> 
>> More difficult would be the use of ‘=‘, ‘!’, and ‘?’ - all legal in Ruby 
>> method names as suffixes.
> 
> Using those would require backquotes:
> 
> x.`what?`() 
> 
> 
> -Chris
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Xiaodi Wu via swift-evolution 
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
all and they very much need to be able to—but how?

On Mon, Nov 20, 2017 at 20:51 Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> 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 fan of compiler magic, but Equatable, Hashable, and
> Comparable are special because they’re the basis for a lot of standard
> library functionality so i think the benefits of making this a special
> supported case outweigh the additional language opacity.
>
>
> I understand your goal, but that compiler magic can’t exist until there is
> something to hook it into.  Tuples can’t conform to protocols right now, so
> there is nothing that can be synthesized.
>
> -Chris
>
>
>
> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner 
> wrote:
>
>>
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> 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 is the time to
>> start thinking about this. i’m also tacking on Comparable to the other
>> two protocols because there is precedent in the language from SE-15
>> 
>> that tuple comparison is something that makes sense to write.
>>
>> EHC conformance is even more important for tuples than it is for structs
>> because tuples effectively have no workaround whereas in structs, you could
>> just manually implement the conformance.
>>
>>
>> In my opinion, you’re approaching this from the wrong direction.  The
>> fundamental problem here is that tuples can’t conform to a protocol.  If
>> they could, synthesizing these conformances would be straight-forward.
>>
>> If you’re interested in pushing this forward, the discussion is “how do
>> non-nominal types like tuples and functions conform to protocols”?
>>
>> -Chris
>>
>>
>>
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 

> 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 like `blank?`, for example?
>> 
>> A: This should be the job of a language-specific interop layer.
> 
> Swift has the backtick syntax for escaping keywords (`identifier`), but it 
> doesn't allow non-identifier characters to be used in identifiers. We might 
> explore loosening that.

Right.

-Chris___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
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 
> static match first, then uses the dynamicMember only as a fallback?

Right.  I added that to the proposal in the “API resilience section”.

> Q: It seems like this fundamentally alters Swift’s aesthetic of “either an 
> operation is type-safe, or it’s clear at the point of use that it’s not.”  
> Should this use an operator other than a period, e.g. `pickle->loads(blob)`?

AnyObject dispatch is the closest relative to this feature that Swift currently 
has, and is neither type safe nor unsurprising. :-)

It is important to note that implementations of this protocol can definitely 
implement it in terms of optionals, so it is completely type safe.  Consider a 
JSON implementation for example: the dynamic getter would return a type of 
“JSON?”.  That design is fully type safe.

> Q: Why the open-ended `associatedtype DynamicMemberLookupValue`? Seems like 
> it will always just be Self in practice.
> 
> A: It would be Self in the Python and JSON examples in the proposal, but 
> making it an associatedtype adds no implementation burden, does no apparent 
> harm, and adds flexibility. Shifting types on traversal could be particularly 
> useful in creating DSLs (e.g. sepia → Genus, sepia.officinalis → Species).

Not necessarily the same.  Consider a bad use of this for sugaring a string to 
int dictionary.  The string “keys” would be the “dynamicMember", but the 
DynamicMemberLookupValue would be the key type: Int. 


> Q: Is there any special handling for that member name string — to handle ruby 
> method names like `blank?`, for example?

A: Use the standard Swift backquote mechanism:   x.`blank?`()


> Q: Should the subscript also take arg types and/or labels to allow 
> overloading?
> 
> A: Ruby, Python, and JS all resolve members by name alone, and leave it to 
> functions to untangle their own args. Obj-C is the lone oddball here. Relying 
> on the companion proposal to handle the args makes sense.

AFAIK, Swift’s subscript model is already general enough to do what we need it 
to do, but if there is some interesting language that isn’t served by it, we 
can talk about that when it comes up.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
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 fan of compiler magic, but Equatable, Hashable, and Comparable are 
> special because they’re the basis for a lot of standard library functionality 
> so i think the benefits of making this a special supported case outweigh the 
> additional language opacity.

I understand your goal, but that compiler magic can’t exist until there is 
something to hook it into.  Tuples can’t conform to protocols right now, so 
there is nothing that can be synthesized.

-Chris


> 
> On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner  > wrote:
> 
>> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 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 is the time to 
>> start thinking about this. i’m also tacking on Comparable to the other two 
>> protocols because there is precedent in the language from SE-15 
>> 
>>  that tuple comparison is something that makes sense to write.
>> 
>> EHC conformance is even more important for tuples than it is for structs 
>> because tuples effectively have no workaround whereas in structs, you could 
>> just manually implement the conformance. 
> 
> In my opinion, you’re approaching this from the wrong direction.  The 
> fundamental problem here is that tuples can’t conform to a protocol.  If they 
> could, synthesizing these conformances would be straight-forward.
> 
> If you’re interested in pushing this forward, the discussion is “how do 
> non-nominal types like tuples and functions conform to protocols”?
> 
> -Chris
> 
> 
> 
> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Ben Rimmington via swift-evolution 
> 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 maybe something like ‘env()’ would work?  I normally try to avoid 
> abbreviations, but we have arch() as precedent.  The word ‘Simulator’ should 
> be what stands out...

Xcode uses `destination`:

e.g. 

e.g. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 

> 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@swift.org>> 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 the second one as an atomic thing, which is I think what 
 you’re getting at. 
>>> 
>>> What if you write ‘let fn = obj.method’?
>> 
>> That’s related to the DynamicMemberLookup proposal.  I’m not familiar with 
>> Ruby, but it sounds like the implementation would end up calling 
>> rb_iv_get/set to manipulate instance variables.  Is that your question or 
>> are you asking something else?
> 
> I don’t think that’s what he is asking. If `method` is indeed a method, then 
> `obj.method` in Ruby would return the method as a `Proc` (If I’m not 
> mistaken), ready to be called, very similarly to how it works in Swift:
> 
> class Foo {
> func bar(_ a: String) {
> print(a)
> }
> }
> 
> let foo = Foo()
> let b = foo.bar
> b()

I’m not going to speculate what Slava meant (please speak up!), but given David 
Waite’s recent email, it isn’t clear that we’d want to provide this.  It seems 
reasonable for a Ruby interop layer to implement the DynamicCallable (in method 
only form?) but not DynamicMemberLookup.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Kelvin Ma via swift-evolution 
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
Comparable are special because they’re the basis for a lot of standard
library functionality so i think the benefits of making this a special
supported case outweigh the additional language opacity.

On Mon, Nov 20, 2017 at 8:42 PM, Chris Lattner  wrote:

>
> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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 is the time to
> start thinking about this. i’m also tacking on Comparable to the other
> two protocols because there is precedent in the language from SE-15
> 
> that tuple comparison is something that makes sense to write.
>
> EHC conformance is even more important for tuples than it is for structs
> because tuples effectively have no workaround whereas in structs, you could
> just manually implement the conformance.
>
>
> In my opinion, you’re approaching this from the wrong direction.  The
> fundamental problem here is that tuples can’t conform to a protocol.  If
> they could, synthesizing these conformances would be straight-forward.
>
> If you’re interested in pushing this forward, the discussion is “how do
> non-nominal types like tuples and functions conform to protocols”?
>
> -Chris
>
>
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 

> 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 definitely argue against the 
former calling a method, even if that is possible in Ruby APIs.

> 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 (although there are 
> shortcuts in normal use, like Symbol#to_proc)

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 where Swift and Python differs 
(e.g. Python slicing syntax vs Swift ranges).  In my opinion, Swift syntax wins 
here, we shouldn’t try to ape a non-native syntax in Swift.

> For mapping to Swift, I would say that parens are needed; we can’t guess 
> whether a `foo.bar` is meant to be asking for the value of attribute bar or a 
> reference to method bar.

+1

> More difficult would be the use of ‘=‘, ‘!’, and ‘?’ - all legal in Ruby 
> method names as suffixes.

Using those would require backquotes:

x.`what?`() 


-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 

> 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 
>  is 
> synthesizing these conformances for tuple types, though it was left out of 
> the original proposal to avoid mission creep. I think now is the time to 
> start thinking about this. i’m also tacking on Comparable to the other two 
> protocols because there is precedent in the language from SE-15 
> 
>  that tuple comparison is something that makes sense to write.
> 
> EHC conformance is even more important for tuples than it is for structs 
> because tuples effectively have no workaround whereas in structs, you could 
> just manually implement the conformance. 

In my opinion, you’re approaching this from the wrong direction.  The 
fundamental problem here is that tuples can’t conform to a protocol.  If they 
could, synthesizing these conformances would be straight-forward.

If you’re interested in pushing this forward, the discussion is “how do 
non-nominal types like tuples and functions conform to protocols”?

-Chris




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread 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 is the time to
start thinking about this. i’m also tacking on Comparable to the other two
protocols because there is precedent in the language from SE-15

that tuple comparison is something that makes sense to write.

EHC conformance is even more important for tuples than it is for structs
because tuples effectively have no workaround whereas in structs, you could
just manually implement the conformance. this is especially relevant in
graphics and scientific contexts where tuples are used to represent color
values and points in 2D or 3D space. today you still can’t do things like

let lattice = Dictionary<(Int, Int, Int), AssociatedValue>() .

the commonly suggested “workaround”, which is to “upgrade” the tuple to a
struct is problematic for two reasons:

1. it defeats the purpose of having tuples in the language

2. tuples are a logical currency type for commonly used types like points
and vectors. If every library defined its own custom point/vector types we
would soon (already?) have a nightmare situation where no geometry/graphics
library would be compatible with any other geometry/graphics library, at
least not without a lot of annoying, let alone wasteful swizzling and
manual conversion routines in the main application.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Jonathan Hull via swift-evolution 

> 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 to see if this is the best name/structure.

If it is just going to be the concept of a simulator, then something like 
isSimulated() might be better.  In the current form, I think we should have 
both ‘Simulator’ and ‘Device’ as options.

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 
maybe something like ‘env()’ would work?  I normally try to avoid 
abbreviations, but we have arch() as precedent.  The word ‘Simulator’ should be 
what stands out...

Would Testing be a possible future environment?

> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
Yes, Definitely!

> Does this proposal fit well with the feel and direction of Swift?
> 
Yes.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
I guess Objective C had something like this as well, which was more powerful, 
but also more messy.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
Quick Read

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Slava Pestov via swift-evolution 


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


How so? It seems that encapsulation is orthogonal to reference/value semantics.

>  e.g. a struct leaks information about the mutation of its member variables, 
> even if those variables are private.

Can you explain what you mean by this?

>  Structs are the obvious implementation for a named tuple (CGPoint 
> CGAffineTransform UIColor etc.) where there is inherently a fixed set of 
> members that are more conveniently accessed directly.  Structs and classes 
> have different purposes and so the argument for consistency with classes is 
> weak.
> 
> With regard to the BalancedPair problem, I would prefer to see a "final 
> struct" or "required init”.

The real reason we want to introduce this language change is to solve some 
problems related to resilience. We want to be able to add new stored properties 
to structs, or change existing stored properties to computed properties (and 
vice versa) without breaking binary or source compatibility. Since 
non-delegating initializers expose the exact set of stored properties to the 
client module, they break the encapsulation that we need to allow this.

Slava
> On November 14, 2017 at 1:31:25 PM, Ted Kremenek (kreme...@apple.com 
> ) wrote:
> 
>> The review of "SE-0189: Restrict Cross-module Struct Initializers" begins 
>> now and runs through November 21, 2017.
>> 
>> The proposal is available here:
>> 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
>>  
>> 
>> Reviews are an important part of the Swift evolution process. All review 
>> feedback should be sent to the swift-evolution mailing list at:
>> 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
>> or, if you would like to keep your feedback private, directly to the review 
>> manager. 
>> 
>> When replying, please try to keep the proposal link at the top of the 
>> message:
>> 
>> Proposal link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
>>  
>> 
>> ...
>> Reply text
>> ...
>> Other replies
>> What goes into a review of a proposal?
>> 
>> The goal of the review process is to improve the proposal under review 
>> through constructive criticism and, eventually, determine the direction of 
>> Swift. 
>> 
>> When reviewing a proposal, here are some questions to consider:
>> 
>> What is your evaluation of the proposal?
>> 
>> Is the problem being addressed significant enough to warrant a change to 
>> Swift?
>> 
>> Does this proposal fit well with the feel and direction of Swift?
>> 
>> If you have used other languages or libraries with a similar feature, how do 
>> you feel that this proposal compares to those?
>> 
>> How much effort did you put into your review? A glance, a quick reading, or 
>> an in-depth study?
>> 
>> Thanks,
>> Ted Kremenek
>> Review Manager
>> ___
>> swift-evolution-announce mailing list
>> swift-evolution-annou...@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Jonathan Hull via swift-evolution 
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 
confusion with the filter method.

I like the idea of introducing compacted() and compactedMap(), though it only 
works if we introduce compacted() at the same time (which I am ok with).  I 
keep expecting it to be a compact map in the topological sense, but I doubt 
that is a problem most will have.


The only real way to get forward transfer here (besides leaving it alone) is to 
do one of the following:

• Use a name used by another language (that doesn’t conflict with Swift)

• Introduce a concept of removing nils in Swift and call it the same 
thing (e.g. compacted)

• Have an awkward, long, and overly specific name like mapAndRemoveNils

I think it might make sense to just drop the quest for forward transfer, and 
instead look for a short, readable, and memorable name that makes sense in 
hindsight once you have seen it (e.g. dropMap?).  That, or introduce a word 
that means to remove nils.

Thanks,
Jon


> On Nov 20, 2017, at 9:22 AM, BJ Homer via swift-evolution 
>  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.filterMap {$0})
>> 
>> filterMap is quite poor for this situation because *each* component in the 
>> term is inaccurate:
> 
> filterMap is indeed an awkward name for this use case, just like flatMap is. 
> In my experience, about half of my use cases use the identity closure, and 
> half actually make use of the closure in a meaningful way. I would support a 
> proposal to add something like Sequence.dropNils (actual name to be 
> determined), and then we could let this proposal target the 
> non-identity-closure use case.
> 
> -BJ
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Rod Brown via swift-evolution 


> 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/0190-target-environment-platform-condition.md
>  
> 
> Reviews are an important part of the Swift evolution process. All review 
> feedback should be sent to the swift-evolution mailing list at:
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. 
> 
> When replying, please try to keep the proposal link at the top of the message:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0190-target-environment-platform-condition.md
>  
> 
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. 
> 
> When reviewing a proposal, here are some questions to consider:
> 
> What is your evaluation of the proposal?
> 
I think it’s good in theory, but I am concerned that there is currently only 
one example case of “simulator”, which also seems somewhat limited to Apple 
Platforms. Would another case “device” make sense?

Also a few questions I have:
How would this be extended to make sense for each platform? Say on platforms 
that actually have an emulator (rather than a simulator) how would this apply 
to those cases?
How does it make sense for the desktop where we could compile on the platform, 
and there would *be* no simulator?
Could there be other relevant cases we can add at other times?
Would these cases only make sense for Platform Vendors or IDEs to manage?
> Does this proposal fit well with the feel and direction of Swift?
> 
I think it makes sense to clean this up. The current checks are remarkably 
obscure and full of unsafe assumptions it would be good to sort out. But I’d 
like to see this solution fleshed out to a solution that is appropriate beyond 
the iOS/tvOS/watchOS ecosystems.
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
No, but I have run into the same problems documented here in Obj-C and Swift.
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
A quick reading.
> Thanks,
> Ted Kremenek
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Erica Sadun via swift-evolution 
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 "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/0190-target-environment-platform-condition.md
>  
> 
> Reviews are an important part of the Swift evolution process. All review 
> feedback should be sent to the swift-evolution mailing list at:
> 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> or, if you would like to keep your feedback private, directly to the review 
> manager. 
> 
> When replying, please try to keep the proposal link at the top of the message:
> 
> Proposal link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0190-target-environment-platform-condition.md
>  
> 
> ...
> Reply text
> ...
> Other replies
> What goes into a review of a proposal?
> 
> The goal of the review process is to improve the proposal under review 
> through constructive criticism and, eventually, determine the direction of 
> Swift. 
> 
> When reviewing a proposal, here are some questions to consider:
> 
> What is your evaluation of the proposal?
> 
> Is the problem being addressed significant enough to warrant a change to 
> Swift?
> 
> Does this proposal fit well with the feel and direction of Swift?
> 
> If you have used other languages or libraries with a similar feature, how do 
> you feel that this proposal compares to those?
> 
> How much effort did you put into your review? A glance, a quick reading, or 
> an in-depth study?
> 
> Thanks,
> Ted Kremenek
> Review Manager
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Erica Sadun via swift-evolution 
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 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:
>> 
>> filterMap is indeed an awkward name for this use case, just like flatMap is. 
>> In my experience, about half of my use cases use the identity closure, and 
>> half actually make use of the closure in a meaningful way. I would support a 
>> proposal to add something like Sequence.dropNils (actual name to be 
>> determined), and then we could let this proposal target the 
>> non-identity-closure use case.
> 
> If the identity closure (i.e. "please remove the nils from this sequence") is 
> a common use case, then I absolutely agree that we should consider adding a 
> specific operation for that, and that name might illuminate the right name 
> for the mapping version.
> 
> John.

Just throwing this out there, but would it be the worst thing in the world if 
`transform: (Optional) throws -> U` defaulted to {item: T in return T}`?

Otherwise, I don't think `removeNils` is necessary as in my experience, the 
optional sequence or array was generated by some kind of transform operation.

-- E

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread David Waite via swift-evolution 
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 (although 
there are shortcuts in normal use, like Symbol#to_proc)

Ruby class implementations often expose a getter and/or setter for instance 
variables - under the function names example_value() and example_value=(). If 
instance variables/class variables are not exposed in this manner, then the 
expectation is that you weren’t meant to see/manipulate them, and do so at your 
own peril.

For mapping to Swift, I would say that parens are needed; we can’t guess 
whether a `foo.bar` is meant to be asking for the value of attribute bar or a 
reference to method bar.

More difficult would be the use of ‘=‘, ‘!’, and ‘?’ - all legal in Ruby method 
names as suffixes. ‘=‘ as already stated is used for setters, ‘!’ for 
differentiating mutating operations, and ‘?’ to indicate the result is boolean 
(or sometimes just ‘truthy’ , as every object other than false and nil evaluate 
to true)

I could imagine tricks to make `foo.bar = 1` work, but I’m not sure what would 
be an appropriate way to represent ! and ? methods.

-DW

> On Nov 20, 2017, at 1:10 PM, 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@swift.org>> 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’?
> 
> That’s related to the DynamicMemberLookup proposal.  I’m not familiar with 
> Ruby, but it sounds like the implementation would end up calling 
> rb_iv_get/set to manipulate instance variables.  Is that your question or are 
> you asking something else?
> 
> -Chris
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread David Hart via swift-evolution 


> 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@swift.org>> 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’?
> 
> That’s related to the DynamicMemberLookup proposal.  I’m not familiar with 
> Ruby, but it sounds like the implementation would end up calling 
> rb_iv_get/set to manipulate instance variables.  Is that your question or are 
> you asking something else?

I don’t think that’s what he is asking. If `method` is indeed a method, then 
`obj.method` in Ruby would return the method as a `Proc` (If I’m not mistaken), 
ready to be called, very similarly to how it works in Swift:

class Foo {
func bar(_ a: String) {
print(a)
}
}

let foo = Foo()
let b = foo.bar
b()

> -Chris
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread 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, 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.filterMap {$0})
>>> 
>>> filterMap is quite poor for this situation because *each* component in the 
>>> term is inaccurate:
>> 
>> filterMap is indeed an awkward name for this use case, just like flatMap is. 
>> In my experience, about half of my use cases use the identity closure, and 
>> half actually make use of the closure in a meaningful way. I would support a 
>> proposal to add something like Sequence.dropNils (actual name to be 
>> determined), and then we could let this proposal target the 
>> non-identity-closure use case.
> 
> If the identity closure (i.e. "please remove the nils from this sequence") is 
> a common use case, then I absolutely agree that we should consider adding a 
> specific operation for that, and that name might illuminate the right name 
> for the mapping version.
> 
> John.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread John McCall via swift-evolution 
> 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.filterMap {$0})
>> 
>> filterMap is quite poor for this situation because *each* component in the 
>> term is inaccurate:
> 
> filterMap is indeed an awkward name for this use case, just like flatMap is. 
> In my experience, about half of my use cases use the identity closure, and 
> half actually make use of the closure in a meaningful way. I would support a 
> proposal to add something like Sequence.dropNils (actual name to be 
> determined), and then we could let this proposal target the 
> non-identity-closure use case.

If the identity closure (i.e. "please remove the nils from this sequence") is a 
common use case, then I absolutely agree that we should consider adding a 
specific operation for that, and that name might illuminate the right name for 
the mapping version.

John.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 

> 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 the second one as an atomic thing, which is I think what 
>> you’re getting at. 
> 
> What if you write ‘let fn = obj.method’?

That’s related to the DynamicMemberLookup proposal.  I’m not familiar with 
Ruby, but it sounds like the implementation would end up calling rb_iv_get/set 
to manipulate instance variables.  Is that your question or are you asking 
something else?

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Drew Crawford via swift-evolution 
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 variables are private.  Structs are the obvious 
implementation for a named tuple (CGPoint CGAffineTransform UIColor etc.) where 
there is inherently a fixed set of members that are more conveniently accessed 
directly.  Structs and classes have different purposes and so the argument for 
consistency with classes is weak.

With regard to the BalancedPair problem, I would prefer to see a "final struct" 
or "required init".
On November 14, 2017 at 1:31:25 PM, Ted Kremenek (kreme...@apple.com) wrote:

The review of "SE-0189: Restrict Cross-module Struct Initializers" begins now 
and runs through November 21, 2017.

The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
Reviews are an important part of the Swift evolution process. All review 
feedback should be sent to the swift-evolution mailing list at:

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review 
manager. 

When replying, please try to keep the proposal link at the top of the message:

Proposal link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md
...
Reply text
...
Other replies
What goes into a review of a proposal?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift. 

When reviewing a proposal, here are some questions to consider:

What is your evaluation of the proposal?

Is the problem being addressed significant enough to warrant a change to Swift?

Does this proposal fit well with the feel and direction of Swift?

If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?

How much effort did you put into your review? A glance, a quick reading, or an 
in-depth study?

Thanks,
Ted Kremenek
Review Manager
___
swift-evolution-announce mailing list
swift-evolution-annou...@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Slava Pestov via swift-evolution 


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

Slava___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Chris Lattner via swift-evolution 
> 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 from a 
> DynamicMemberLookupProtocol type) fits Python like a glove, where everything 
> (including functions) is a PyVal. But in other languages, like Ruby, this 
> model makes less sense.

Right, this was also brought up in the DynamicCallable thread, the example 
given before was Squeak, another Smalltalky language.

It turns out that the right ultimate design for DynamicCallable is probably to 
have two different entry points: one for direct-function-like calls and one for 
methods-with-keywords calls, e.g.:

fn(arg: 1, arg2: 2)   // function like
obj.method(arg: 1, arg2: 2)   // method like

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.  I plan to revise the DynamicCallable proposal to incorporate this 
directly into the model, but haven’t had time to do so yet.

-Chris




> For example, here is how one uses the Ruby C API to call a method of an 
> object:
> 
> result = rb_funcallv(obj, rb_intern(“methodName"), arg_count, args);
> 
> And here is how one gets and sets instance variables:
> 
> x = rb_iv_get(obj, "@x");
> rb_iv_set(obj, "@x", x);
> 
> 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, how would one implement DynamicMemberLookupProtocol for the 
> lookup of bar, and what would the return value be? Its entirely context 
> sensitive.
> 
> If we want a model that fits the most languages, shouldn’t we redefine 
> DynamicCallable to specify the function name?
> 
> protocol DynamicCallable {
> associatedtype DynamicCallableArgument
> associatedtype DynamicCallableResult
> 
> func dynamicCall(function: String, arguments: [(String, 
> DynamicCallableArgument)]) throws -> DynamicCallableResult
> }
> 
> This would work in both languages:
> 
> extension PyVal: DynamicMemberLookupProtocol, DynamicCallable {
> func dynamicCall(function: String, arguments: [(String, PyVal)]) throws 
> -> PyVal {
> let functionVal = self[function]
> functionVal.call(arguments)
> }
> }
> 
> extension RbVal: DynamicMemberLookupProtocol, DynamicCallable {
> func dynamicCall(function: String, arguments: [(String, PyVal)]) throws 
> -> PyVal {
> return rb_funcallv(self, rb_intern(function), arguments.count, 
> arguments);
> }
> }
> 
> Thoughts?
> David.
> 
>> On 20 Nov 2017, at 03:16, Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi all,
>> 
>> As I mentioned on a couple other threads, I’ve been working on improving 
>> Swift interoperability with Python.  I have two pitches out: one to improve 
>> Python member lookup and one to improve calls to Python values.  While those 
>> proposals are important, I think it is also useful to see what can be 
>> accomplished with Swift today.
>> 
>> To show you how far we can get, here is a Swift playground (tested with 
>> Xcode 9) that has an example interoperability layer, and a tutorial for 
>> using it.  If you’re interested in the pitches, or in Python, please check 
>> it out:
>> 
>> 
>> 
>> In addition to showing how far the interop can go today (which is really 
>> quite far) it shows what the future will look like assuming the member 
>> lookup and call issues are resolved.  To reiterate what I said on the pitch 
>> threads, I am not attached at all to the details of the two pitches 
>> themselves, I simply want the problems they address to be solved.
>> 
>> Finally, of course I also welcome questions and feedback on the actual 
>> approach, naming, and other suggestions to improve the model!  Thanks,
>> 
>> -Chris
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread BJ Homer via swift-evolution 


> 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 the 
> term is inaccurate:

filterMap is indeed an awkward name for this use case, just like flatMap is. In 
my experience, about half of my use cases use the identity closure, and half 
actually make use of the closure in a meaningful way. I would support a 
proposal to add something like Sequence.dropNils (actual name to be 
determined), and then we could let this proposal target the 
non-identity-closure use case.

-BJ

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Drew Crawford via swift-evolution 
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 "filter" 
carries a specific meaning involving booleans.  In particular if `a` were of 
type `[Bool?]` I believe new Swift programmers would fail to predict the result
2.  This is not a map operation when used with the identity closure.  

Most of the discussion so far addresses 1 but not 2, e.g. mapSome, mapCompact 
improve dimension 1 but not dimension 2.

I support mapMaybe because from the choices so far it is the only one that 
seems to address both dimensions.

It can also be argued that the combined API itself is a mistake, e.g. that a 
distinct API for discarding optionals as from mapping would be superior.  But 
that may be too radical at this point.

On November 15, 2017 at 2:55:10 PM, John McCall (rjmcc...@apple.com) wrote:

Hello, Swift Community!

The initial review of "SE-0187: Introduce Sequence.filterMap(_:)" ran through 
yesterday, November 14th, 2017.  The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md

There was a significant amount of discussion, and people came down with 
reasonable arguments both for and against the proposal.  After reviewing that 
feedback, the core team feels that the central question is whether Swift 
benefits from overloading flatMap in this way.  There is a reasonable argument 
that an Optional is a sort of container, and therefore it makes sense to 
"flatten" that container into a surrounding container.  But Swift has resisted 
applying that interpretation in its library design; for example, you cannot 
directly iterate an Optional or append its contents to an Array.  In general, 
we feel that using different operations for working with Optionals tends to 
make code easier to both write and understand, especially given the existence 
of implicit optional promotion, which we cannot eliminate or easily suppress 
based on the context.  On reflection, we think it was a mistake to use the same 
name in the first place, and there is no better time to fix a mistake than now.

While we accept that this will cause some amount of "code churn" for developers 
when they adopt Swift 5, the required change is a simple rename that should be 
painless to automatically migrate.  Of course, sample code on the internet will 
become obsolete, but fix-its will easily update that code if pasted into a 
project, and the samples themselves (once corrected) should become clearer and 
easier to teach after this change, as is generally true when overloading is 
removed.

Accordingly, SE-0187 is accepted, at least as far as not calling the operation 
"flatMap".  We are re-opening the review until next Monday, November 20th, 
2017, in order to have a focused discussion about the new name.  Names that 
seemed to gain some traction in the first review include:

  - filterMap, which has precedent in existing functional languages, as well as 
some popular Swift libraries, but which some people view as confusing

  - compactMap, which builds off the precedent of "compact" in Ruby

But please feel free to suggest a name other than these.

Reviews

Reviews are an important part of the Swift evolution process.  All reviews 
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to me as the 
review manager.  When replying, please try to keep the proposal link at the top 
of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md
Reply text
Other replies
What goes into a review?

The goal of the review process is to improve the proposal under review through 
constructive criticism and, eventually, determine the direction of Swift.

When writing your review, here are some questions you might want to answer in 
your review:

• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to 
Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do 
you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or 
an in-depth study?

More information about the Swift evolution process is available at:

https://github.com/apple/swift-evolution/blob/master/process.md

As always, thank you for contributing to the evolution of Swift.

John McCall
Review Manager
___
swift-evolution-announce mailing list
swift-evolution-annou...@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

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

2017-11-20 Thread Paul Cantrell via swift-evolution 


> 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:
>>> 
 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:
 
 class Foo
   def initialize()
 @bar = 5
   end
 
   def bar()
 puts “Hello"
   end
 end
 
 In that case, how would one implement DynamicMemberLookupProtocol for the 
 lookup of bar, and what would the return value be? Its entirely context 
 sensitive.
>>> 
>>> I do not believe Ruby does not give you direct external access to 
>>> variables. Everything with a ‘.’ is a function call.
>>> 
>>> You would use e.g.
>>> 
>>> Foo.new.instance_variable_get("@bar”) // => 5
>>> 
>>> attr :bar exposes a variable @bar through functions bar() and bar=()   (and 
>>> also optimizes storage in some implementations)
>> 
>> This is correct…sort of. Ruby uses symbols to refer to both methods and 
>> instance variables, but instance variable symbols always start with @, so 
>> they effectively belong to a different namespace. (Similarly, symbols 
>> starting with a capital letter are for constants; symbols starting with @@ 
>> are for class variables; I believe symbols starting with $ are for global 
>> variables.) Ruby only provides syntax to access another object's methods and 
>> (for a class) constants, so in practice there's no way to access another 
>> object's instance variables except by calling a method on it, but there's no 
>> particular reason our bridge would need to follow that rule.

Just to add a little weight to what Brent wrote here: in Ruby, one can •only• 
access instance variables of self using the @bar syntax. There is no such thing 
as “foo.@bar”; as Brent wrote, one can only access another object — not even 
another class, but another object! — via its methods.

Class authors thus expect @bar to be private (well, same-instance protected), 
and instance_variable_get/set is the accepted in-Ruby hack to fiddle with 
another object’s internal state. I see no reason a bridge would need to deviate 
from that understanding.

>> 
>> Leaving aside those technicalities, it's pretty clear that `foo.bar` should 
>> access a method, not an instance variabl, when `foo` is a Ruby object. That 
>> doesn't mean it's the same as Python, though, because in Ruby it will need 
>> to *call* the method immediately if we're to provide natural syntax for Ruby 
>> objects bridged to Swift.
> 
> Exactly. My example was a bit contrived but that’s what I wanted to say.

X-ref to a thread where we discussed this at greater length:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171113/041447.html
 


Cheers,

Paul___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Matt Whiteside via swift-evolution 
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 work on this.  Thanks.
> 
> They are. If you take a look at recent pull requests at 
> , you'll see all sorts 
> of conditional-conformance-related stuff is being worked on right now.
> 
> In fact, the first conditional conformances (making Array, Dictionary, and 
> Optional conform to Equatable) briefly landed a few days ago: 
>  Unfortunately, they had to be 
> backed out because they broke a couple tests, but that's software 
> development, right?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread David Hart via swift-evolution 


> 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:
>>> 
>> 
>> 
>>> 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, how would one implement DynamicMemberLookupProtocol for the 
>>> lookup of bar, and what would the return value be? Its entirely context 
>>> sensitive.
>> 
>> I do not believe Ruby does not give you direct external access to variables. 
>> Everything with a ‘.’ is a function call.
>> 
>> You would use e.g.
>> 
>> Foo.new.instance_variable_get("@bar”) // => 5
>> 
>> attr :bar exposes a variable @bar through functions bar() and bar=()   (and 
>> also optimizes storage in some implementations)
> 
> This is correct…sort of. Ruby uses symbols to refer to both methods and 
> instance variables, but instance variable symbols always start with @, so 
> they effectively belong to a different namespace. (Similarly, symbols 
> starting with a capital letter are for constants; symbols starting with @@ 
> are for class variables; I believe symbols starting with $ are for global 
> variables.) Ruby only provides syntax to access another object's methods and 
> (for a class) constants, so in practice there's no way to access another 
> object's instance variables except by calling a method on it, but there's no 
> particular reason our bridge would need to follow that rule.
> 
> Leaving aside those technicalities, it's pretty clear that `foo.bar` should 
> access a method, not an instance variable, when `foo` is a Ruby object. That 
> doesn't mean it's the same as Python, though, because in Ruby it will need to 
> *call* the method immediately if we're to provide natural syntax for Ruby 
> objects bridged to Swift.

Exactly. My example was a bit contrived but that’s what I wanted to say.

> Bottom line: Ruby cannot be bridged naturally with just an undifferentiated 
> "access member" hook. It needs separate "access property" and "access method" 
> hooks.
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Brent Royal-Gordon via swift-evolution 
> 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:
>> 
>> class Foo
>>   def initialize()
>> @bar = 5
>>   end
>> 
>>   def bar()
>> puts “Hello"
>>   end
>> end
>> 
>> In that case, how would one implement DynamicMemberLookupProtocol for the 
>> lookup of bar, and what would the return value be? Its entirely context 
>> sensitive.
> 
> I do not believe Ruby does not give you direct external access to variables. 
> Everything with a ‘.’ is a function call.
> 
> You would use e.g.
> 
> Foo.new.instance_variable_get("@bar”) // => 5
> 
> attr :bar exposes a variable @bar through functions bar() and bar=()   (and 
> also optimizes storage in some implementations)

This is correct…sort of. Ruby uses symbols to refer to both methods and 
instance variables, but instance variable symbols always start with @, so they 
effectively belong to a different namespace. (Similarly, symbols starting with 
a capital letter are for constants; symbols starting with @@ are for class 
variables; I believe symbols starting with $ are for global variables.) Ruby 
only provides syntax to access another object's methods and (for a class) 
constants, so in practice there's no way to access another object's instance 
variables except by calling a method on it, but there's no particular reason 
our bridge would need to follow that rule.

Leaving aside those technicalities, it's pretty clear that `foo.bar` should 
access a method, not an instance variable, when `foo` is a Ruby object. That 
doesn't mean it's the same as Python, though, because in Ruby it will need to 
*call* the method immediately if we're to provide natural syntax for Ruby 
objects bridged to Swift.

Bottom line: Ruby cannot be bridged naturally with just an undifferentiated 
"access member" hook. It needs separate "access property" and "access method" 
hooks.

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread David Waite via swift-evolution 


> 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, how would one implement DynamicMemberLookupProtocol for the 
> lookup of bar, and what would the return value be? Its entirely context 
> sensitive.

I do not believe Ruby does not give you direct external access to variables. 
Everything with a ‘.’ is a function call.

You would use e.g.

Foo.new.instance_variable_get("@bar”) // => 5

attr :bar exposes a variable @bar through functions bar() and bar=()   (and 
also optimizes storage in some implementations)

-DW___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Goffredo Marocchi via swift-evolution 
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:
>> 
>> 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 
> , you'll see all sorts 
> of conditional-conformance-related stuff is being worked on right now.
> 
> In fact, the first conditional conformances (making Array, Dictionary, and 
> Optional conform to Equatable) briefly landed a few days ago: 
>  Unfortunately, they had to be 
> backed out because they broke a couple tests, but that's software 
> development, right?
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread David Hart via swift-evolution 
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 
approval.

David.

> On 20 Nov 2017, at 09:16, David Hart via swift-evolution 
>  wrote:
> 
> 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, where everything 
> (including functions) is a PyVal. But in other languages, like Ruby, this 
> model makes less sense.
> 
> For example, here is how one uses the Ruby C API to call a method of an 
> object:
> 
> result = rb_funcallv(obj, rb_intern(“methodName"), arg_count, args);
> 
> And here is how one gets and sets instance variables:
> 
> x = rb_iv_get(obj, "@x");
> rb_iv_set(obj, "@x", x);
> 
> 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, how would one implement DynamicMemberLookupProtocol for the 
> lookup of bar, and what would the return value be? Its entirely context 
> sensitive.
> 
> If we want a model that fits the most languages, shouldn’t we redefine 
> DynamicCallable to specify the function name?
> 
> protocol DynamicCallable {
> associatedtype DynamicCallableArgument
> associatedtype DynamicCallableResult
> 
> func dynamicCall(function: String, arguments: [(String, 
> DynamicCallableArgument)]) throws -> DynamicCallableResult
> }
> 
> This would work in both languages:
> 
> extension PyVal: DynamicMemberLookupProtocol, DynamicCallable {
> func dynamicCall(function: String, arguments: [(String, PyVal)]) throws 
> -> PyVal {
> let functionVal = self[function]
> functionVal.call(arguments)
> }
> }
> 
> extension RbVal: DynamicMemberLookupProtocol, DynamicCallable {
> func dynamicCall(function: String, arguments: [(String, PyVal)]) throws 
> -> PyVal {
> return rb_funcallv(self, rb_intern(function), arguments.count, 
> arguments);
> }
> }
> 
> Thoughts?
> David.
> 
>> On 20 Nov 2017, at 03:16, Chris Lattner via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> Hi all,
>> 
>> As I mentioned on a couple other threads, I’ve been working on improving 
>> Swift interoperability with Python.  I have two pitches out: one to improve 
>> Python member lookup and one to improve calls to Python values.  While those 
>> proposals are important, I think it is also useful to see what can be 
>> accomplished with Swift today.
>> 
>> To show you how far we can get, here is a Swift playground (tested with 
>> Xcode 9) that has an example interoperability layer, and a tutorial for 
>> using it.  If you’re interested in the pitches, or in Python, please check 
>> it out:
>> 
>> 
>> 
>> In addition to showing how far the interop can go today (which is really 
>> quite far) it shows what the future will look like assuming the member 
>> lookup and call issues are resolved.  To reiterate what I said on the pitch 
>> threads, I am not attached at all to the details of the two pitches 
>> themselves, I simply want the problems they address to be solved.
>> 
>> Finally, of course I also welcome questions and feedback on the actual 
>> approach, naming, and other suggestions to improve the model!  Thanks,
>> 
>> -Chris
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Brent Royal-Gordon via swift-evolution 
> 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 
, you'll see all sorts 
of conditional-conformance-related stuff is being worked on right now.

In fact, the first conditional conformances (making Array, Dictionary, and 
Optional conform to Equatable) briefly landed a few days ago: 
 Unfortunately, they had to be 
backed out because they broke a couple tests, but that's software development, 
right?

-- 
Brent Royal-Gordon
Architechies

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread David Hart via swift-evolution 
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, where everything 
(including functions) is a PyVal. But in other languages, like Ruby, this model 
makes less sense.

For example, here is how one uses the Ruby C API to call a method of an object:

result = rb_funcallv(obj, rb_intern(“methodName"), arg_count, args);

And here is how one gets and sets instance variables:

x = rb_iv_get(obj, "@x");
rb_iv_set(obj, "@x", x);

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, how would one implement DynamicMemberLookupProtocol for the 
lookup of bar, and what would the return value be? Its entirely context 
sensitive.

If we want a model that fits the most languages, shouldn’t we redefine 
DynamicCallable to specify the function name?

protocol DynamicCallable {
associatedtype DynamicCallableArgument
associatedtype DynamicCallableResult

func dynamicCall(function: String, arguments: [(String, 
DynamicCallableArgument)]) throws -> DynamicCallableResult
}

This would work in both languages:

extension PyVal: DynamicMemberLookupProtocol, DynamicCallable {
func dynamicCall(function: String, arguments: [(String, PyVal)]) throws -> 
PyVal {
let functionVal = self[function]
functionVal.call(arguments)
}
}

extension RbVal: DynamicMemberLookupProtocol, DynamicCallable {
func dynamicCall(function: String, arguments: [(String, PyVal)]) throws -> 
PyVal {
return rb_funcallv(self, rb_intern(function), arguments.count, 
arguments);
}
}

Thoughts?
David.

> On 20 Nov 2017, at 03:16, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi all,
> 
> As I mentioned on a couple other threads, I’ve been working on improving 
> Swift interoperability with Python.  I have two pitches out: one to improve 
> Python member lookup and one to improve calls to Python values.  While those 
> proposals are important, I think it is also useful to see what can be 
> accomplished with Swift today.
> 
> To show you how far we can get, here is a Swift playground (tested with Xcode 
> 9) that has an example interoperability layer, and a tutorial for using it.  
> If you’re interested in the pitches, or in Python, please check it out:
> 
> 
> 
> In addition to showing how far the interop can go today (which is really 
> quite far) it shows what the future will look like assuming the member lookup 
> and call issues are resolved.  To reiterate what I said on the pitch threads, 
> I am not attached at all to the details of the two pitches themselves, I 
> simply want the problems they address to be solved.
> 
> Finally, of course I also welcome questions and feedback on the actual 
> approach, naming, and other suggestions to improve the model!  Thanks,
> 
> -Chris
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

2017-11-20 Thread Goffredo Marocchi via swift-evolution 
+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: if you are reading this, please allow the swift compiler 
> team the bandwidth to work on this.  Thanks.
> 
> -Matt
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution