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

[C. Keith Ray via swift-evolution]

BTW, Java via JNI would be another good application of this proposal. I once 
used a JNI wrapper library in C++ and it was pretty hairy and tedious.

I think we might want to declare a "Python object" as implementing swift 
protocols. If the methods that implement a protocol are NOT implemented in 
Swift, then the python code should be called -- the names already match. 
Otherwise the developer the has to map the protocol methods and properties to 
the Python methods, etc.

C. Keith Ray
https://leanpub.com/wepntk <- buy my book?
http://agilesolutionspace.blogspot.com/
twitter: @ckeithray
http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf

On Dec 4, 2017, at 7:30 PM, Chris Lattner  wrote:

>>> On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution 
>>>  wrote:
>>> The first one, has no static type info, no compile time checking, it's not 
>>> self documenting, no type inference so people will be forced to use a 
>>> dynamic reference at the call site to store the result, leading to more 
>>> type loss, and all this spirals down.
>>> I'm already starting to fear dynamic.
>>> Edit: The danger has passed (Phew!) ... and dynamic wasn't been abused 
>>> after all, no need to down vote me after 3 years :)
>> 
>> From what I can gather, `dynamic` is used when declaring types, but there's 
>> no indication at call sites that what is being invoked is dynamic. And it 
>> even allows for casting basically anything to the `dynamic` type.
>> 
>> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/dynamic
>> 
>> So here we have a language community that was (is?) very vocal about caution 
>> when it comes to type inference with `var`, but seems to have accepted the 
>> validity of `dynamic`. This seems to show that at least one community has 
>> absorbed this sort of change (arguably a more "dangerous" version than what 
>> is being proposed here) with no real issues.
> 
> Right.  dynamic in C# is far broader (and more “dangerous”) than what I’m 
> proposing.  That said, because there have been absolutely zero specific 
> examples of the sorts of harm DynamicMemberLookup could cause, it is 
> difficult to speculate about exactly which boogieman people are afraid of.
> 
>> So I have a few questions:
>> 
>> - Would it be enough to require annotation of the dynamic nature of a type 
>> at the declaration sites, if that still means the call sites aren't 
>> explicitly annotated? 
> 
> It is impossible to solve a problem if it cannot be explained in enough 
> detail to provide examples.  Personally, I don’t see the problem at all.
> 
>> - Why do some think the Swift community would be more at risk of abuse of 
>> this feature than the C# community seems to have been? 
> 
> 
> People are making bizarre claims about what the spirit of Swift is, informing 
> me of things which are obviously not true, and ignoring the evidence I 
> present to them.  This is doubly humorous given that I have a fairly good 
> sense for the design balance and tradeoffs of existing features in Swift 
> today, along with detailed rationale for why they were added, when, and all 
> of the discussion that backed them.  I chalk this up to the fear of the 
> unknown or perhaps a mistrust for the peers these people work with.
> 
> My goal is to make the design and proposal writeup as good as possible, and 
> the fear mongering about abuse has led me to add several options for further 
> narrowing the potential for abuse, including to the point of requiring every 
> new adoptee to go through the Swift evolution process for review.  During the 
> review period for DynamicMemberLookup, people who carry these concerns are 
> welcome to +1 one or more of those.
> 
> I personally am far more interested in getting to the bottom of Doug’s 
> concerns - it isn’t clear to me what exactly his preferred direction actually 
> is, but that discussion is based on engineering tradeoffs and may well lead 
> to a change to the proposal or a complete change in direction.
> 
> -Chris
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[C. Keith Ray via swift-evolution]

Not everyone uses the IDE as a crutch for writing code. As someone who has used 
many languages, editors, and operating systems, I don't rely on autocomplete 
and sometimes turn it off because it gets in my way.

my experience with C# was sometimes frustrating because it could be hard to 
find the return type of a function, or the type of a "var" variable. Xcode's 
playgrounds, faster search, and "print(type(of:x))" provides a nicer experience.

(you should try Resharper and C# to see what refactoring support should look 
like.)

C. Keith Ray
https://leanpub.com/wepntk <- buy my book?
http://agilesolutionspace.blogspot.com/
twitter: @ckeithray
http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf

> On Dec 4, 2017, at 8:32 PM, Joe DeCapo  wrote:
> 
>> On Dec 4, 2017, at 9:30 PM, Chris Lattner  wrote:
>> 
>> I personally am far more interested in getting to the bottom of Doug’s 
>> concerns - it isn’t clear to me what exactly his preferred direction 
>> actually is, but that discussion is based on engineering tradeoffs and may 
>> well lead to a change to the proposal or a complete change in direction.
>> 
>> -Chris
> 
> Some notes on one of Doug's points:
> 
>> * Indexing/jump-to-definition/lookup documentation/generated interface won’t 
>> ever work. None of the IDE features supported by SourceKit will work, which 
>> will be a significant regression for users coming from a Python-capable IDE.
> 
> Here's the state of the art in PyCharm in my personal Python project (no type 
> hints, but full comprehensive doc comments):
> 
> 
> 
> 
> 
> 
> 
> PyCharm is able to get the trivial cases right, but anything more complex 
> than definitions and calls contained in a single file tend to end up looking 
> something like that. I don't see any way that Swift could improve on that, 
> and it's a foreign experience to anyone used to developing Swift code in 
> Xcode.
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe DeCapo via swift-evolution]

> On Dec 4, 2017, at 9:30 PM, Chris Lattner  > wrote:
> 
> I personally am far more interested in getting to the bottom of Doug’s 
> concerns - it isn’t clear to me what exactly his preferred direction actually 
> is, but that discussion is based on engineering tradeoffs and may well lead 
> to a change to the proposal or a complete change in direction.
> 
> -Chris

Some notes on one of Doug's points:

> * Indexing/jump-to-definition/lookup documentation/generated interface won’t 
> ever work. None of the IDE features supported by SourceKit will work, which 
> will be a significant regression for users coming from a Python-capable IDE.

Here's the state of the art in PyCharm in a personal Python project (no type 
hints, but full comprehensive doc comments):

https://www.dropbox.com/s/ob54qalshf6gqth/Screenshot%202017-12-04%2022.11.22.png?dl=0
 


https://www.dropbox.com/s/drw6991u512g456/Screenshot%202017-12-04%2022.11.47.png?dl=0
 


https://www.dropbox.com/s/h8wuy91r1hfnsvj/Screenshot%202017-12-04%2022.12.05.png?dl=0
 


PyCharm is able to get the trivial cases right, but any of the more complex 
cases tend to end up looking something like that. I don't see any way that 
Swift could improve on that, and it's still a foreign experience to anyone used 
to developing Swift code in Xcode.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Christopher Kornher via swift-evolution]

> On Dec 4, 2017, at 1:12 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> On 04.12.2017 19:27, Joe DeCapo via swift-evolution wrote:
>>> On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution 
>>> > wrote:
>>> 
>>> 1_ From what i understood from this discussion (please correct me if i'm 
>>> wrong) python code is already callable from swift right now, without any 
>>> modification to the compiler, but then the syntax to *some* very generic 
>>> python function would just not be really pretty. If it's just library 
>>> calls, we could just wrap those calls into pretty functions for our needs, 
>>> but then :
>> I think it's worthwhile to add this syntactic sugar to make wrapper 
>> libraries easier to write and reason about. From Chris's example playground:
>> let d = np.call(member: "array", args: Python.array(6, 7, 8),
>> kwargs: [("dtype", "i2")])
>> // Python:d = np.array([1, 2, 3], dtype="i2")
>> // Future Swift:  let d = np.array([6, 7, 8], dtype: "i2")
>> It's far easier (at least for me) to read the sugared Swift version and 
>> understand what it is doing than how it's currently required to be written.
> 
> Yes, it is easier to read, if you just wrote this. But not easier to 
> understand when you are looking into some one's code during the debugging to 
> try to understand what is not working exactly, where is the normal static 
> code and where is next dynamic call.
> I strongly believe that dynamic code should not looks like normal "static" 
> code in Swift, because this is not expected by *Swift* developer.  When we 
> look on method name/property *we* expect it is defined somewhere, we can find 
> definition, we know what rules are applied to that "object" like method or 
> property.
> 
> I'll be glad if more people use Swift, I think that Python/Ruby/etc interop 
> could be useful and we need ergonomic syntax for this, but I don't agree that 
> we should change Swift to be more comfortable for non-Swift devs when this 
> change complicates live of Swift devs.
> 
> Probably the correct way to have dynamic calls in Swift is to 'mark' such 
> code with special flag and we need to find it. For example:
> 
> > // Python:d = np.array([1, 2, 3], dtype="i2")
> > // Future Swift:  let d = np.@array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np@array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np:array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np.~array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np.@array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np."array"([6, 7, 8], dtype: "i2") // name of 
> > dynamic method is like just string, no any guarantee & we can have any 
> > needed symbol in string to express the details of target dynamic 
> > language(if needed)
> > // etc

Unless I am mistaken, an intelligent editor would have enough information to 
demarcate dynamic calls which would accomplish your objective without the need 
for a heavy-handed differentiated call syntax.

This is not relying upon tooling, it is allowing tooling to do what it is 
supposed to: augment the development experience in accordance with a 
developer’s needs.


> 
> Yes, IMO such code should be second class citizen in Swift.
> 
> AnyObject's dynamic calls are not available on Linux, so their existence for 
> apple platforms is just a required feature to talk to ObjC runtime, with 
> headers\annotations for available methods/props, tooling supports. So IMO we 
> can't make our decisions regarding "true" dynamic code design based on how 
> AnyObject's semi-dynamic calls are designed, IMO they are two separate things.
> 
> Vladimir.
> 
>> I'm sure it's true that people coming from a background in a dynamic 
>> language will initially write "bad" Swift code. When I first started writing 
>> Python, I wrote it like Swift/Objective-C/Bash. But eventually I learned 
>> more of the common idioms in Python and rewrote my code to use those idioms. 
>> This is a bridge to allow easy access to the vast number of libraries that 
>> currently exist in those dynamic language domains, and to ease the 
>> transition of the multitudes of those programmers into Swift.
>> From everything I've seen in the Swift community so far, I have faith that 
>> we collectively won't abuse this feature to the point that it poisons what 
>> Swift has achieved so far. And I'm not against some type of "guardrails" 
>> that help prevent unintentional misuse, but I'd like for it not to be so 
>> much as to be punishing to those that want to make use of the proposed 
>> features.
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

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

[Chris Lattner via swift-evolution]

> On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution 
>  wrote:
>> The first one, has no static type info, no compile time checking, it's not 
>> self documenting, no type inference so people will be forced to use a 
>> dynamic reference at the call site to store the result, leading to more type 
>> loss, and all this spirals down.
>> I'm already starting to fear dynamic.
>> Edit: The danger has passed (Phew!) ... and dynamic wasn't been abused after 
>> all, no need to down vote me after 3 years :)
> 
> From what I can gather, `dynamic` is used when declaring types, but there's 
> no indication at call sites that what is being invoked is dynamic. And it 
> even allows for casting basically anything to the `dynamic` type.
> 
> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/dynamic
> 
> So here we have a language community that was (is?) very vocal about caution 
> when it comes to type inference with `var`, but seems to have accepted the 
> validity of `dynamic`. This seems to show that at least one community has 
> absorbed this sort of change (arguably a more "dangerous" version than what 
> is being proposed here) with no real issues.

Right.  dynamic in C# is far broader (and more “dangerous”) than what I’m 
proposing.  That said, because there have been absolutely zero specific 
examples of the sorts of harm DynamicMemberLookup could cause, it is difficult 
to speculate about exactly which boogieman people are afraid of.

> So I have a few questions:
> 
> - Would it be enough to require annotation of the dynamic nature of a type at 
> the declaration sites, if that still means the call sites aren't explicitly 
> annotated? 

It is impossible to solve a problem if it cannot be explained in enough detail 
to provide examples.  Personally, I don’t see the problem at all.

> - Why do some think the Swift community would be more at risk of abuse of 
> this feature than the C# community seems to have been? 


People are making bizarre claims about what the spirit of Swift is, informing 
me of things which are obviously not true, and ignoring the evidence I present 
to them.  This is doubly humorous given that I have a fairly good sense for the 
design balance and tradeoffs of existing features in Swift today, along with 
detailed rationale for why they were added, when, and all of the discussion 
that backed them.  I chalk this up to the fear of the unknown or perhaps a 
mistrust for the peers these people work with.

My goal is to make the design and proposal writeup as good as possible, and the 
fear mongering about abuse has led me to add several options for further 
narrowing the potential for abuse, including to the point of requiring every 
new adoptee to go through the Swift evolution process for review.  During the 
review period for DynamicMemberLookup, people who carry these concerns are 
welcome to +1 one or more of those.

I personally am far more interested in getting to the bottom of Doug’s concerns 
- it isn’t clear to me what exactly his preferred direction actually is, but 
that discussion is based on engineering tradeoffs and may well lead to a change 
to the proposal or a complete change in direction.

-Chris

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

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

[Joe DeCapo via swift-evolution]

> On Dec 4, 2017, at 7:22 PM, Joe DeCapo via swift-evolution 
>  wrote:
> 
>> The first one, has no static type info, no compile time checking, it's not 
>> self documenting, no type inference so people will be forced to use a 
>> dynamic reference at the call site to store the result, leading to more type 
>> loss, and all this spirals down.
> 
> From what I can gather, `dynamic` is used when declaring types, but there's 
> no indication at call sites that what is being invoked is dynamic.

Upon rereading, I had assumed one could use `var` at the call site, but that 
may not be true. Even so, at the most there's still only one call site 
reference required, not for every following call site invocation.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Joe DeCapo via swift-evolution]

I'm curious to get some feedback on this from people who would prefer a marker 
at every call site where a `DynamicMemberLookup` or `DynamicCallable` type is 
used. I haven't done any C# development before, but I read a few articles on 
the usage of `dynamic` and `var` in the language. I found it interesting that 
there are a number of posts cautioning against the use of `var` in C# for type 
inference, in preference to explicitly specifying types.

https://www.brad-smith.info/blog/archives/336
https://www.intertech.com/Blog/the-use-and-abuse-of-the-c-var-keyword/
https://weblogs.asp.net/stevewellens/can-the-c-var-keyword-be-misused
https://blogs.msdn.microsoft.com/ericlippert/2011/04/20/uses-and-misuses-of-implicit-typing/

It's almost comical to read those from the vantage point of a Swift developer, 
given that we tend to avoid explicit typing in every scenario we can, save for 
those where it's required. And I think most would agree that we've suffered no 
real problems due to it.

C# 3.0 introduced the `var` keyword in 2007. In 2010, C# 4.0 introduced the 
`dynamic` keyword. Here are a couple of quotes from devs about the `dynamic` 
keyword:

https://www.codeproject.com/Articles/69407/The-Dynamic-Keyword-in-C

> Earlier, I said that my initial reaction was negative, so what changed my 
> mind? To quote Margret Attwood, context is all.

https://stackoverflow.com/a/245537

> The first one, has no static type info, no compile time checking, it's not 
> self documenting, no type inference so people will be forced to use a dynamic 
> reference at the call site to store the result, leading to more type loss, 
> and all this spirals down.
> I'm already starting to fear dynamic.
> Edit: The danger has passed (Phew!) ... and dynamic wasn't been abused after 
> all, no need to down vote me after 3 years :)

From what I can gather, `dynamic` is used when declaring types, but there's no 
indication at call sites that what is being invoked is dynamic. And it even 
allows for casting basically anything to the `dynamic` type.

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/dynamic

So here we have a language community that was (is?) very vocal about caution 
when it comes to type inference with `var`, but seems to have accepted the 
validity of `dynamic`. This seems to show that at least one community has 
absorbed this sort of change (arguably a more "dangerous" version than what is 
being proposed here) with no real issues.

So I have a few questions:

- Would it be enough to require annotation of the dynamic nature of a type at 
the declaration sites, if that still means the call sites aren't explicitly 
annotated? 
- Is it really much different to require annotation with a keyword at type 
declaration sites, than to just inspect the type for conformance to 
`DynamicMemberLookup` and/or `DynamicCallable` (especially now that Chris added 
sections to the proposal forbidding retroactive conformance and the option of 
not allowing it as part of another protocol definition)? Admittedly it's one 
extra step of indirection when investigating an issue, but I assume we could 
have reasonable error messages nudging us toward the specific problem.
- Why do some think the Swift community would be more at risk of abuse of this 
feature than the C# community seems to have been? 

And if there's anyone with experience in C# where this was actually a 
legitimate issue, I would be happy to hear about your experience.

-Joe

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

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

[C. Keith Ray via swift-evolution]

> Yes, IMO such code should be second class citizen in Swift.

Just have the compiler emit "your code is bad and you should be ashamed of it."

--
C. Keith Ray

* https://leanpub.com/wepntk <- buy my book?
* http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf
* http://agilesolutionspace.blogspot.com/

> On Dec 4, 2017, at 12:12 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> Yes, IMO such code should be second class citizen in Swift.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Rick Mann via swift-evolution]

> On Dec 3, 2017, at 08:33 , Michel Fortin via swift-evolution 
>  wrote:
> 
> Instead of looking for a module in the _module search path_, the compiler 
> would run a command-line tool called `py2swift` found in an _import tool 
> search path_. The tool generates the module on the fly before returning the 
> module path to the compiler, who can then continue with compiling.

Just a small concern: it should not run a command-line tool (i.e. exec a 
process). Everything should be library calls, so that the compiler can be 
embedded in other environments cleanly.

-- 
Rick Mann
rm...@latencyzero.com


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

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

[Chris Lattner via swift-evolution]

> On Dec 4, 2017, at 12:12 PM, Vladimir.S via swift-evolution 
>  wrote:
> 
> Probably the correct way to have dynamic calls in Swift is to 'mark' such 
> code with special flag and we need to find it. For example:
> 
> > // Python:d = np.array([1, 2, 3], dtype="i2")
> > // Future Swift:  let d = np.@array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np@array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np:array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np.~array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np.@array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np."array"([6, 7, 8], dtype: "i2") // name of 
> > dynamic method is like just string, no any guarantee & we can have any 
> > needed symbol in string to express the details of target dynamic 
> > language(if needed)
> > // etc
> 
> Yes, IMO such code should be second class citizen in Swift.

This idea was discussed extensively upthread, and has been specifically 
addressed in the proposal:
https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#increasing-visibility-of-dynamic-member-lookups
 


-Chris

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

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

[Ben Cohen via swift-evolution]

> On Dec 4, 2017, at 10:53, Karl Wagner  wrote:
> 
> But you noted in that thread that "(Int.min.. you can fit in an Int, and causes a crash today. If we remove IndexDistance, 
> that behaviour is locked-in, is it not?
> 

That behavior is going to be locked in whether we like it or not when we 
declare ABI stability of the Range type, irrespective of the presence of an 
IndexDistance associated type. An alternative design for Range would require 
reworking Int.Stride to be of size > Int, something that is probably not 
realistic even if resolving this issue merited it (which, IMO, it does not).

There are always going to be edge cases and unfortunate limitations. What we 
must guard against, when trying to reconcile them, is solutions that result in 
complexity (and often more edge cases…) far worse than the original problem. I 
see this as clearly the case here. IndexDistance is already too complex: 
confusing for beginners and annoying for experienced users. Increasing the 
complexity not just of Collection, but of Int’s conformance to Strideable, and 
of some of the most commonly used concrete types, in order to provide a 
marginal benefit, falls firmly on the wrong side of the cost/benefit analysis. 
This is, of course, a subjective judgement. But we mustn’t let this 
subjectivity paralyze us into resisting improvements in the hope of finding the 
perfect solution that everyone can agree is free of tradeoffs. Such solutions 
rarely exist.

> I would love to make generic programming against Collection more convenient, 
> but that seems like quite a large cost which wasn’t made clear in the 
> proposal. I also note that people only expressed support for the proposal 
> before Xiaodi pointed it out, and not afterwards (although its possible my 
> email program missed/misplaced some messages, it does happen...).
> 

The review ran through December 3rd. Xiaodi’s comment about range distances was 
on November 30th. There was plenty of time left in the review after it for 
further comment, and for those who originally endorsed but then realized this 
edge case changed matters to rescind their endorsement.

> - Karl
> 
>> On 4. Dec 2017, at 19:39, Ben Cohen via swift-evolution 
>> > wrote:
>> 
>> They will continue to conform to Collection just as they do today. 
>> Range.IndexDistance is already an Int.
>> 
>>> On Dec 4, 2017, at 10:35, Karl Wagner via swift-evolution 
>>> > wrote:
>>> 
>>> What does this mean for ranges of integers, as Xiaodi mentioned in the 
>>> review thread? Can they still conform to Collection? 
>>> 
>>> I think we really need clarification on that aspect. Personally, I would 
>>> consider it a deal-breaker.
>>> 
>>> - Karl
>>> 
 On 4. Dec 2017, at 18:57, Douglas Gregor via swift-evolution 
 > wrote:
 
 Proposal Link: 
 https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
  
 
 
 Hello Swift Community,
 
 The review of SE-0191 "Eliminate IndexDistance from Collection” ran from 
 November 27…December 3, 2017. The proposal is accepted. Feedback for this 
 simplification to the Collection protocols was positive.
 
 Thank you to everyone who participated in the review!
 
Doug Gregor
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 
>>> 
>> 
>> ___
>> 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: Introduce User-defined "Dynamic Member Lookup" Types

[Vladimir.S via swift-evolution]

On 04.12.2017 19:27, Joe DeCapo via swift-evolution wrote:


On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution > wrote:


1_ From what i understood from this discussion (please correct me if i'm wrong) python code is already callable from 
swift right now, without any modification to the compiler, but then the syntax to *some* very generic python function 
would just not be really pretty. If it's just library calls, we could just wrap those calls into pretty functions for 
our needs, but then :


I think it's worthwhile to add this syntactic sugar to make wrapper libraries easier to write and reason about. From 
Chris's example playground:


let d = np.call(member: "array", args: Python.array(6, 7, 8),
 kwargs: [("dtype", "i2")])
// Python:d = np.array([1, 2, 3], dtype="i2")
// Future Swift:  let d = np.array([6, 7, 8], dtype: "i2")

It's far easier (at least for me) to read the sugared Swift version and understand what it is doing than how it's 
currently required to be written.


Yes, it is easier to read, if you just wrote this. But not easier to understand when you are looking into some one's 
code during the debugging to try to understand what is not working exactly, where is the normal static code and where is 
next dynamic call.
I strongly believe that dynamic code should not looks like normal "static" code in Swift, because this is not expected 
by *Swift* developer.  When we look on method name/property *we* expect it is defined somewhere, we can find definition, 
we know what rules are applied to that "object" like method or property.


I'll be glad if more people use Swift, I think that Python/Ruby/etc interop could be useful and we need ergonomic syntax 
for this, but I don't agree that we should change Swift to be more comfortable for non-Swift devs when this change 
complicates live of Swift devs.


Probably the correct way to have dynamic calls in Swift is to 'mark' such code with special flag and we need to find it. 
For example:


> // Python:d = np.array([1, 2, 3], dtype="i2")
> // Future Swift:  let d = np.@array([6, 7, 8], dtype: "i2")
> // Future Swift:  let d = np@array([6, 7, 8], dtype: "i2")
> // Future Swift:  let d = np:array([6, 7, 8], dtype: "i2")
> // Future Swift:  let d = np.~array([6, 7, 8], dtype: "i2")
> // Future Swift:  let d = np.@array([6, 7, 8], dtype: "i2")
> // Future Swift:  let d = np."array"([6, 7, 8], dtype: "i2") // name of dynamic method is like just string, no any 
guarantee & we can have any needed symbol in string to express the details of target dynamic language(if needed)

> // etc

Yes, IMO such code should be second class citizen in Swift.

AnyObject's dynamic calls are not available on Linux, so their existence for apple platforms is just a required feature 
to talk to ObjC runtime, with headers\annotations for available methods/props, tooling supports. So IMO we can't make 
our decisions regarding "true" dynamic code design based on how AnyObject's semi-dynamic calls are designed, IMO they 
are two separate things.


Vladimir.



I'm sure it's true that people coming from a background in a dynamic language will initially write "bad" Swift code. 
When I first started writing Python, I wrote it like Swift/Objective-C/Bash. But eventually I learned more of the common 
idioms in Python and rewrote my code to use those idioms. This is a bridge to allow easy access to the vast number of 
libraries that currently exist in those dynamic language domains, and to ease the transition of the multitudes of those 
programmers into Swift.


 From everything I've seen in the Swift community so far, I have faith that we collectively won't abuse this feature to 
the point that it poisons what Swift has achieved so far. And I'm not against some type of "guardrails" that help 
prevent unintentional misuse, but I'd like for it not to be so much as to be punishing to those that want to make use of 
the proposed features.



___
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: Introduce User-defined "Dynamic Member Lookup" Types

[Tino Heth via swift-evolution]

> It is easy to forsee the impact.  Simply look to other language communities 
> that have done similar things.  C# added “dynamic” late in its evolution, 
> which has even more power than what is being proposed here.  What evidence of 
> abuse have you seen?
None, and I have little fear of abuse in general. But I don’t see any benefits 
either (in Swift).

I also never feared abuse of currying, C-style for loops or post increment — 
yet people had strong motivations to remove those features.

Right now, some people say the proposed changes will be terrible, and others 
say they will be wonderful.
All what I’m saying is that real experience would be better than theories.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Chris Lattner via swift-evolution]

On Dec 4, 2017, at 10:47 AM, Eagle Offshore via swift-evolution 
 wrote:
> Hi Magnus,
> 
> You raise an excellent point.
> 
> The swift journey has been interesting to watch, for sure.  I do not believe 
> anyone has ever started with a rigidly typed system and then tried to make it 
> more dynamic (Java JVM dynamicInvocation work by Bracha notwithstanding).

C#’s dynamic feature is an example of this.

> Bottom line - I want to see the proof too.  I think everything should be 
> DynamicLookupable - especially library code since the library creator cannot 
> know in advance how his code may be used and it may well want to be bridged 
> from another environment but then I have been doing a lot of bridging of 
> Pharo Smalltalk to native C libraries via FFI lately and I firmly believe 
> bridges need to run both ways.

I think it is possible that you fundamentally misunderstand the proposal.  It 
does not make it so you can find the members of a type dynamically (as in 
“reflection").  It allows a type to define custom behavior for otherwise 
failing lookups.

-Chris

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

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

[Karl Wagner via swift-evolution]

But you noted in that thread that "(Int.min.. On 4. Dec 2017, at 19:39, Ben Cohen via swift-evolution 
>  wrote:
> 
> They will continue to conform to Collection just as they do today. 
> Range.IndexDistance is already an Int.
> 
>> On Dec 4, 2017, at 10:35, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>> What does this mean for ranges of integers, as Xiaodi mentioned in the 
>> review thread? Can they still conform to Collection? 
>> 
>> I think we really need clarification on that aspect. Personally, I would 
>> consider it a deal-breaker.
>> 
>> - Karl
>> 
>>> On 4. Dec 2017, at 18:57, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> 
>>> Proposal Link: 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
>>>  
>>> 
>>> 
>>> Hello Swift Community,
>>> 
>>> The review of SE-0191 "Eliminate IndexDistance from Collection” ran from 
>>> November 27…December 3, 2017. The proposal is accepted. Feedback for this 
>>> simplification to the Collection protocols was positive.
>>> 
>>> Thank you to everyone who participated in the review!
>>> 
>>> Doug Gregor
>>> 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
> 
> ___
> 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: Introduce User-defined "Dynamic Member Lookup" Types

[Eagle Offshore via swift-evolution]

Hi Magnus,

You raise an excellent point.

The swift journey has been interesting to watch, for sure.  I do not believe 
anyone has ever started with a rigidly typed system and then tried to make it 
more dynamic (Java JVM dynamicInvocation work by Bracha notwithstanding).  
There have been several languages that started out as purely dynamic that then 
added optional type annotations to get compilers to be a little more helpful.  
Strongtalk, Objective C v1, etc.  But starting out with a rigid static bias and 
trying to add in dynamic features seems a lot harder than going the other way.

Anyhow, I have heard for years this argument about how helpful compilers are 
when there is abundant type information.

My experience leaves me personally skeptical but more to the point - where's 
the actual proof?

Here's a blog post with a lot of links to studies trying to assess whether 
static-type heavy systems actually reduce defects and make people more 
productive.
https://danluu.com/empirical-pl/

Don't just read the page, follow the links and read the studies.

This continues to be argued at YCombinator. 
https://news.ycombinator.com/item?id=15384351

And there is this discussion of a talk called "The unreasonable effectiveness 
of dynamic typing".
https://games.greggman.com/game/dynamic-typing-static-typing/

Bottom line - I want to see the proof too.  I think everything should be 
DynamicLookupable - especially library code since the library creator cannot 
know in advance how his code may be used and it may well want to be bridged 
from another environment but then I have been doing a lot of bridging of Pharo 
Smalltalk to native C libraries via FFI lately and I firmly believe bridges 
need to run both ways.

It is easy to bridge Objective C from Smalltalk.  Swift, OTOH, looks nigh 
impossible as it is.

> On Dec 4, 2017, at 10:20 AM, Magnus Ahltorp via swift-evolution 
>  wrote:
> 
> 
>> 5 Dec. 2017 01:08 Benjamin G via swift-evolution  
>> wrote:
>> 
>> Unless DynamicLookup is used to circumvent every compiler warning or errors 
>> thrown at you by the language because your design is unsound. Something like 
>> "ho, yeah swift generics and protocols aren't really working fine together 
>> for your case, but just make everything DynamicLookupable and you'll be all 
>> set". Or "This JSON document has a really complex schema. Let's just not 
>> specify anything, and call the fields like this, you won't even feel any 
>> difference anyway".
> 
> We have heard these horror tales about everyone making "everything 
> DynamicLookupable" and this being extremely bad, but can anyone actually 
> produce a believable example? It's not like it's absurdly convenient to 
> implement this, the ergonomics are at the call site, not the implementation. 
> It sounds like you think that just conforming to DynamicMemberLookupProtocol 
> and DynamicCallable will magically make everything in the code dynamic with 
> no extra effort.
> 
> /Magnus
> 
> ___
> 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: Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner via swift-evolution]

> On Dec 4, 2017, at 10:28 AM, Tino Heth <2...@gmx.de> wrote:
> 
> 
>> The strongest your argument can be is “someone could use dynamic member 
>> lookup in their API to produce an API with a footgun that hurts their 
>> users”.  I submit for your consideration that there are lots and lots of 
>> ways that people can create poor APIs that hurt users.  If someone uses this 
>> feature inappropriately, then their API is crappy and you shouldn’t use it, 
>> just like any other misuse of languages features.  
> 
> 
> The two proposals have benefits, but they have risks as well — and imho 
> nobody can foresee their full impact now.

It is easy to forsee the impact.  Simply look to other language communities 
that have done similar things.  C# added “dynamic” late in its evolution, which 
has even more power than what is being proposed here.  What evidence of abuse 
have you seen?

-Chris


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

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

[Ben Cohen via swift-evolution]

They will continue to conform to Collection just as they do today. 
Range.IndexDistance is already an Int.

> On Dec 4, 2017, at 10:35, Karl Wagner via swift-evolution 
>  wrote:
> 
> What does this mean for ranges of integers, as Xiaodi mentioned in the review 
> thread? Can they still conform to Collection? 
> 
> I think we really need clarification on that aspect. Personally, I would 
> consider it a deal-breaker.
> 
> - Karl
> 
>> On 4. Dec 2017, at 18:57, Douglas Gregor via swift-evolution 
>> > wrote:
>> 
>> Proposal Link: 
>> https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
>>  
>> 
>> 
>> Hello Swift Community,
>> 
>> The review of SE-0191 "Eliminate IndexDistance from Collection” ran from 
>> November 27…December 3, 2017. The proposal is accepted. Feedback for this 
>> simplification to the Collection protocols was positive.
>> 
>> Thank you to everyone who participated in the review!
>> 
>>  Doug Gregor
>>  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

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

Re: [swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

[Karl Wagner via swift-evolution]

What does this mean for ranges of integers, as Xiaodi mentioned in the review 
thread? Can they still conform to Collection? 

I think we really need clarification on that aspect. Personally, I would 
consider it a deal-breaker.

- Karl

> On 4. Dec 2017, at 18:57, Douglas Gregor via swift-evolution 
>  wrote:
> 
> Proposal Link: 
> https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
>  
> 
> 
> Hello Swift Community,
> 
> The review of SE-0191 "Eliminate IndexDistance from Collection” ran from 
> November 27…December 3, 2017. The proposal is accepted. Feedback for this 
> simplification to the Collection protocols was positive.
> 
> Thank you to everyone who participated in the review!
> 
>   Doug Gregor
>   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] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Tino Heth via swift-evolution]

> The strongest your argument can be is “someone could use dynamic member 
> lookup in their API to produce an API with a footgun that hurts their users”. 
>  I submit for your consideration that there are lots and lots of ways that 
> people can create poor APIs that hurt users.  If someone uses this feature 
> inappropriately, then their API is crappy and you shouldn’t use it, just like 
> any other misuse of languages features.  

I wish that attitude had more weight in the past, when things like forbidding 
inheritance or adding warnings for unused results were discussed…
You can write stupid code in every real programming language, no matter how 
safe it claims to be, so you can’t argue against a feature just by pointing out 
that it can be misused.

But I guess many people got the impression that Swift tries very hard to 
protect us:
Things like let and struct help ensuring that things aren’t changed 
unexpectedly (and sometimes, you are forced to acknowledge that a parameter can 
be changed with „&“), Optionals help to eliminate nil-value problems, and a 
strong type system protects us from trying to call methods that aren’t there.
Now we are talking about something that allows us to call methods that "aren’t 
there“, and although I wouldn’t call it a footgun, it’s definitely a huge 
change for the language. Even if it is no contradiction to the spirit of Swift 
(who could decide that if not you?), big changes tend to make people afraid — 
especially under the prospect that they might come before next year, and will 
stay forever.
Yes, dynamic dispatch isn’t completely new to Swift, but you barely notice that 
Cocoa-types have special rules (unless you have to keep it in mind because you 
implement those rules in the compiler).

The two proposals have benefits, but they have risks as well — and imho nobody 
can foresee their full impact now.
Therefor, I’m convinced they should not be accepted under the normal terms:
Look back at what renaming private to fileprivate did to Swift, and all the 
churn that could have been avoided with a trial phase.

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

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

[Dave DeLong via swift-evolution]

Awesome. The thread has gotten so long and forked that it’s hard to keep track 
of what has been asked and answered. I’ll check these out and get back if I 
have more questions.

Thanks!  

Dave

> On Dec 4, 2017, at 11:20 AM, Chris Lattner  wrote:
> 
> It could work, but is a much worse approach IMO.  The proposal discusses it 
> here:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#motivation-and-context
>  
> 
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#direct-language-support-for-python-and-all-the-other-languages
>  
> 
> 
> Doug has been suggesting similar directions upthread, when he has a chance to 
> respond to my questions, I’ll do a detailed comparison of the approaches.
> 
> -Chris
> 
>> On Dec 4, 2017, at 10:05 AM, Dave DeLong > > wrote:
>> 
>> Hi Chris,
>> 
>> We do the Swift integration with Objective-C via modules. Why wouldn’t that 
>> approach work with Python? Or if it would, why would we favor this dynamic 
>> member lookup over importing a Python API via a module?
>> 
>> Dave
>> 
>>> On Nov 26, 2017, at 11:04 PM, Chris Lattner via swift-evolution 
>>> > wrote:
>>> 
>>> I’d like to formally propose the inclusion of user-defined dynamic member 
>>> lookup types.
>>> 
>>> Here is my latest draft of the proposal:
>>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 
>>> 
>>> https://github.com/apple/swift-evolution/pull/768
>>> 
>>> An implementation of this design is available here:
>>> https://github.com/apple/swift/pull/13076
>>> 
>>> The implementation is straight-forward and (IMO) non-invasive in the 
>>> compiler.
>>> 
>>> -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: Introduce User-defined "Dynamic Member Lookup" Types

[Chris Lattner via swift-evolution]

It could work, but is a much worse approach IMO.  The proposal discusses it 
here:
https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#motivation-and-context
 

https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#direct-language-support-for-python-and-all-the-other-languages
 


Doug has been suggesting similar directions upthread, when he has a chance to 
respond to my questions, I’ll do a detailed comparison of the approaches.

-Chris

> On Dec 4, 2017, at 10:05 AM, Dave DeLong  wrote:
> 
> Hi Chris,
> 
> We do the Swift integration with Objective-C via modules. Why wouldn’t that 
> approach work with Python? Or if it would, why would we favor this dynamic 
> member lookup over importing a Python API via a module?
> 
> Dave
> 
>> On Nov 26, 2017, at 11:04 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> I’d like to formally propose the inclusion of user-defined dynamic member 
>> lookup types.
>> 
>> Here is my latest draft of the proposal:
>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
>> https://github.com/apple/swift-evolution/pull/768
>> 
>> An implementation of this design is available here:
>> https://github.com/apple/swift/pull/13076
>> 
>> The implementation is straight-forward and (IMO) non-invasive in the 
>> compiler.
>> 
>> -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: Introduce User-defined "Dynamic Member Lookup" Types

[Magnus Ahltorp via swift-evolution]

> 5 Dec. 2017 01:08 Benjamin G via swift-evolution  
> wrote:
> 
> Unless DynamicLookup is used to circumvent every compiler warning or errors 
> thrown at you by the language because your design is unsound. Something like 
> "ho, yeah swift generics and protocols aren't really working fine together 
> for your case, but just make everything DynamicLookupable and you'll be all 
> set". Or "This JSON document has a really complex schema. Let's just not 
> specify anything, and call the fields like this, you won't even feel any 
> difference anyway".

We have heard these horror tales about everyone making "everything 
DynamicLookupable" and this being extremely bad, but can anyone actually 
produce a believable example? It's not like it's absurdly convenient to 
implement this, the ergonomics are at the call site, not the implementation. It 
sounds like you think that just conforming to DynamicMemberLookupProtocol and 
DynamicCallable will magically make everything in the code dynamic with no 
extra effort.

/Magnus

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

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

[Jacob Williams via swift-evolution]

> On Dec 4, 2017, at 11:05 AM, Dave DeLong via swift-evolution 
>  wrote:
> 
> Hi Chris,
> 
> We do the Swift integration with Objective-C via modules. Why wouldn’t that 
> approach work with Python? Or if it would, why would we favor this dynamic 
> member lookup over importing a Python API via a module?
> 

My understanding is that we would then have to write modules for each and every 
dynamic language people would want to import. It would take a lot more 
time/maintenance than this approach which theoretically allows for any dynamic 
language to become interoperable with much less effort and very little 
maintenance.

> Dave
> 
>> On Nov 26, 2017, at 11:04 PM, Chris Lattner via swift-evolution 
>>  wrote:
>> 
>> I’d like to formally propose the inclusion of user-defined dynamic member 
>> lookup types.
>> 
>> Here is my latest draft of the proposal:
>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
>> https://github.com/apple/swift-evolution/pull/768
>> 
>> An implementation of this design is available here:
>> https://github.com/apple/swift/pull/13076
>> 
>> The implementation is straight-forward and (IMO) non-invasive in the 
>> compiler.
>> 
>> -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: Introduce User-defined "Dynamic Member Lookup" Types

[Dave DeLong via swift-evolution]

Hi Chris,

We do the Swift integration with Objective-C via modules. Why wouldn’t that 
approach work with Python? Or if it would, why would we favor this dynamic 
member lookup over importing a Python API via a module?

Dave

> On Nov 26, 2017, at 11:04 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
> I’d like to formally propose the inclusion of user-defined dynamic member 
> lookup types.
> 
> Here is my latest draft of the proposal:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438
> https://github.com/apple/swift-evolution/pull/768
> 
> An implementation of this design is available here:
> https://github.com/apple/swift/pull/13076
> 
> The implementation is straight-forward and (IMO) non-invasive in the compiler.
> 
> -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: Introduce User-defined "Dynamic Member Lookup" Types

[Magnus Ahltorp via swift-evolution]

> 5 Dec. 2017 02:25 Joe DeCapo via swift-evolution  
> wrote:
> 
>> On Dec 4, 2017, at 11:15 AM, Tino Heth <2...@gmx.de> wrote:
>> 
>>> 
>>> This is a bridge to allow easy access to the vast number of libraries that 
>>> currently exist in those dynamic language domains, and to ease the 
>>> transition of the multitudes of those programmers into Swift.
>> 
>> I’ve read several posts that gave me the impression that Python has a huge 
>> user base of people who are tired of using that language (the cited 
>> statement is just an arbitrary pick)… but is that actually true?
>> Afaik, Python never became as common as Java, C# or C++, and it never had 
>> much support from big companies — people decided to use Python not because 
>> it’s some sort of standard, but because they liked it and found it to be a 
>> language that’s easy to learn.
>> 
>> So the whole story of „let’s make it easier for those poor Python guys to 
>> switch to a real language“ sounds very much like hubris to me.
>> Of course, that statement is an exaggeration, but still:
>> Did anyone ever ask the Python-community who actually wants to switch to 
>> Swift? I don’t think there would be enough positive feedback to take it as a 
>> justification for the proposed changes.
> 
> That's not really what I meant, and I haven't gotten the impression that 
> that's the main motivating reason. Partly it's for the benefit of the Swift 
> community to leverage many currently existing, mature libraries that exist 
> but are written in dynamic languages. And it makes it possible for someone 
> interested in trying out Swift who has experience with those libraries to 
> still be able to leverage the things they're already familiar with during the 
> transition. There may not be an overwhelming number of developers who have to 
> work in these languages but would prefer Swift, but I don't think there 
> necessarily needs to be for this to still be a worthwhile change.

Yes, there are many of us that have extensive experience with both Python and 
Swift, and many more who have experience with Python libraries that want to 
write their code in Swift because it fits better with some other part of their 
project. Maybe not because they want to desert Python, and maybe not because 
they love Swift, but because it's a better way to solve that particular problem.

Before Swift existed, I wrote high-level parts of a project in Python because 
it was untenable to do it in Objective-C (it was actually much easier for me to 
write a bridge *and* the Python code than to write it in Objective-C), but now 
I have rewritten those parts in Swift, because I could throw out the Python 
runtime and write interface code and logic code in the same language. I didn't 
depend on any critical Python libraries, but others will, and if they want to 
write Cocoa code in Swift, they have to have a Python bridge, and the 
probability that a high-quality Python bridge will exist is much lower if the 
syntax is awful. This of course goes for other dynamically typed languages as 
well.

/Magnus

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

[swift-evolution] [Accepted] SE-0191: Eliminate IndexDistance from Collection

[Douglas Gregor via swift-evolution]

Proposal Link: 
https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md

Hello Swift Community,

The review of SE-0191 "Eliminate IndexDistance from Collection” ran from 
November 27…December 3, 2017. The proposal is accepted. Feedback for this 
simplification to the Collection protocols was positive.

Thank you to everyone who participated in the review!

Doug Gregor
Review Manager___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Review] SE-0191: Eliminate IndexDistance from Collection

[Douglas Gregor via swift-evolution]

> On Nov 29, 2017, at 9:21 AM, Wallacy via swift-evolution 
>  wrote:
> 
> Distances, yes... Count, not necessarily. 

It doesn’t really help you to have an extra bit of range for “count" that can’t 
be expressed in the distance, i.e., where c.count returns a value but 
c.distance(from: c.startIndex, to: c.endIndex) overflows.

- Doug

> 
> 
> Em qua, 29 de nov de 2017 às 15:17, Xiaodi Wu  > escreveu:
> Distance must be signed, so it cannot be UInt.
> On Wed, Nov 29, 2017 at 11:14 Wallacy  > wrote:
> I think is that's why some folks ask for count be UInt (or UInt64 when 
> appropriate) some time ago.
> 
> I dont know how solve this, but appear to be less painful than current 
> IndexDistance.
> 
> Em qua, 29 de nov de 2017 às 14:46, Ben Cohen via swift-evolution 
> > escreveu:
> You can argue the current status is a bug, but…
> 
> Welcome to Apple Swift version 4.0.1 (swiftlang-900.0.67 clang-900.0.38). 
> Type :help for assistance.
>   1> CountableRange.IndexDistance.self
> $R0: Int.Type = Int
>   2> (Int64.min.. Execution interrupted. Enter code to recover and continue.
> 
>> On Nov 29, 2017, at 4:04 AM, Xiaodi Wu > > wrote:
>> 
>> So that we are all clear on the implications of this, if IndexDistance 
>> becomes Int, ranges of integers will stop conforming to Collection, because 
>> Int.min..> potentially many more.
>> 
>> This would entail nontrivial source breakage.
>> 
>> 
>> On Mon, Nov 27, 2017 at 22:02 Ben Cohen via swift-evolution 
>> > wrote:
>> My suggestion would be: don’t have your Collection-like type conform to 
>> Collection. Give it collection-like methods if you want them, like an 
>> indexing and slicing subscript that takes an Int64. It can still conform to 
>> Sequence.
>> 
>> In practice, these “huge” collections will be mostly used concretely, so 
>> their Collection conformance doesn’t buy you much. The reality is that very 
>> few generic uses on these types will succeed. You get a few things like 
>> .first, .last etc. for free. But very few algorithms are written to handle > 
>> Int.max lengths (several in the std lib don’t) – it just isn’t practical. 
>> And meanwhile, this is a huge burden on many other use cases.
>> 
>> The existence of the memory mapped file case is hypothetical. I canvassed a 
>> bit on twitter for some use cases. The only one I got back was where someone 
>> was using IndexDistance to stash other information: but this isn’t really a 
>> legal use of IndexDistance, since it must be numerically castable to other 
>> integer types when needed which would be a lossy operation so at best, it 
>> would just be an optimization.
>> 
>>> On Nov 27, 2017, at 19:29, Nevin Brackett-Rozinsky via swift-evolution 
>>> > wrote:
>>> 
>>> The proposal mentions one reasonable situation where a larger-than-Int type 
>>> would be useful, namely a Collection wrapping a memory-mapped file, being 
>>> used on 32-bit systems.
>>> 
>>> Is there a recommended migration strategy for this scenario?
>>> 
>>> Nevin
>>> 
>>> 
>>> On Mon, Nov 27, 2017 at 8:34 PM, Douglas Gregor via swift-evolution 
>>> > wrote:
>>> Hello Swift community,
>>> 
>>> The review of SE-0191 "Eliminate IndexDistance from Collection" begins now 
>>> and runs through December 3, 2017. The proposal is available here:
>>> 
>>> https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md
>>>  
>>> 
>>> 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 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/0191-eliminate-indexdistance.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 

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

[Joe DeCapo via swift-evolution]

> On Dec 4, 2017, at 11:15 AM, Tino Heth <2...@gmx.de> wrote:
> 
>> 
>> This is a bridge to allow easy access to the vast number of libraries that 
>> currently exist in those dynamic language domains, and to ease the 
>> transition of the multitudes of those programmers into Swift.
> 
> I’ve read several posts that gave me the impression that Python has a huge 
> user base of people who are tired of using that language (the cited statement 
> is just an arbitrary pick)… but is that actually true?
> Afaik, Python never became as common as Java, C# or C++, and it never had 
> much support from big companies — people decided to use Python not because 
> it’s some sort of standard, but because they liked it and found it to be a 
> language that’s easy to learn.
> 
> So the whole story of „let’s make it easier for those poor Python guys to 
> switch to a real language“ sounds very much like hubris to me.
> Of course, that statement is an exaggeration, but still:
> Did anyone ever ask the Python-community who actually wants to switch to 
> Swift? I don’t think there would be enough positive feedback to take it as a 
> justification for the proposed changes.

That's not really what I meant, and I haven't gotten the impression that that's 
the main motivating reason. Partly it's for the benefit of the Swift community 
to leverage many currently existing, mature libraries that exist but are 
written in dynamic languages. And it makes it possible for someone interested 
in trying out Swift who has experience with those libraries to still be able to 
leverage the things they're already familiar with during the transition. There 
may not be an overwhelming number of developers who have to work in these 
languages but would prefer Swift, but I don't think there necessarily needs to 
be for this to still be a worthwhile change.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Tino Heth via swift-evolution]

> This is a bridge to allow easy access to the vast number of libraries that 
> currently exist in those dynamic language domains, and to ease the transition 
> of the multitudes of those programmers into Swift.

I’ve read several posts that gave me the impression that Python has a huge user 
base of people who are tired of using that language (the cited statement is 
just an arbitrary pick)… but is that actually true?
Afaik, Python never became as common as Java, C# or C++, and it never had much 
support from big companies — people decided to use Python not because it’s some 
sort of standard, but because they liked it and found it to be a language 
that’s easy to learn.

So the whole story of „let’s make it easier for those poor Python guys to 
switch to a real language“ sounds very much like hubris to me.
Of course, that statement is an exaggeration, but still:
Did anyone ever ask the Python-community who actually wants to switch to Swift? 
I don’t think there would be enough positive feedback to take it as a 
justification for the proposed changes.

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

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

[Chris Lattner via swift-evolution]

> On Dec 4, 2017, at 1:42 AM, Vincent Esche via swift-evolution 
>  wrote:
> 
> I think the argument basically is "let's not add another footgun" (because 
> the design of Swift , for example regarding null handling, is to have less 
> footguns than other languages). The fact that there are footguns in swift 
> isn't an argument for adding new ones.
> 
> Couldn’t have said it better. This is what it all boils down to.


This is not a “footgun” in the traditional sense, because it does not affect 
someone who does not actively use it.  It is not like UB in C.

The strongest your argument can be is “someone could use dynamic member lookup 
in their API to produce an API with a footgun that hurts their users”.  I 
submit for your consideration that there are lots and lots of ways that people 
can create poor APIs that hurt users.  If someone uses this feature 
inappropriately, then their API is crappy and you shouldn’t use it, just like 
any other misuse of languages features.  

I also haven’t seen demonstration of an example where someone would 
non-maliciously [1] use it in an API, where it would cause harm, and what kind 
of harm that would be.  You are creating a boogieman without taking any effort 
to explain the problem, so there is no way to do a cost benefit tradeoff 
analysis of whether the “benefit” of this feature is worth the “cost” that you 
claim exists. 

I have said everything I intend to say about this topic.

-Chris

[1] Obviously if the API you are using was maliciously crafted, then you have 
tons of other problems.  

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

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

[Joe DeCapo via swift-evolution]

> On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution 
>  wrote:
> 
> 1_ From what i understood from this discussion (please correct me if i'm 
> wrong) python code is already callable from swift right now, without any 
> modification to the compiler, but then the syntax to *some* very generic 
> python function would just not be really pretty. If it's just library calls, 
> we could just wrap those calls into pretty functions for our needs, but then 
> : 

I think it's worthwhile to add this syntactic sugar to make wrapper libraries 
easier to write and reason about. From Chris's example playground:

let d = np.call(member: "array", args: Python.array(6, 7, 8),
kwargs: [("dtype", "i2")])
// Python:d = np.array([1, 2, 3], dtype="i2")
// Future Swift:  let d = np.array([6, 7, 8], dtype: "i2")

It's far easier (at least for me) to read the sugared Swift version and 
understand what it is doing than how it's currently required to be written.

I'm sure it's true that people coming from a background in a dynamic language 
will initially write "bad" Swift code. When I first started writing Python, I 
wrote it like Swift/Objective-C/Bash. But eventually I learned more of the 
common idioms in Python and rewrote my code to use those idioms. This is a 
bridge to allow easy access to the vast number of libraries that currently 
exist in those dynamic language domains, and to ease the transition of the 
multitudes of those programmers into Swift.

>From everything I've seen in the Swift community so far, I have faith that we 
>collectively won't abuse this feature to the point that it poisons what Swift 
>has achieved so far. And I'm not against some type of "guardrails" that help 
>prevent unintentional misuse, but I'd like for it not to be so much as to be 
>punishing to those that want to make use of the proposed features.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Benjamin G via swift-evolution]

On Mon, Dec 4, 2017 at 1:45 PM, Nick Keets via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> Some people are big fans of dynamic behavior and this feature will make
>> it much easier to write code in that style.  They will do it without
>> feeling malicious or considering this to be abusive, considering it to be a
>> legitimate style preference.  I wouldn’t be surprised to see people develop
>> mixins that implement the subscript using mirror and other future
>> reflection capabilities without considering that to be abusive (I would
>> almost be surprised if this *didn’t* happen).  Requiring some kind of
>> usage site annotation would both discourage this and help anyone who walks
>> into a such a code base to understand what is going on.
>>
>
>
> I really don't understand this fear of metamorphosis. People could also be
> using emoji for all their variables. So what? Let them do it!
>
> Are you afraid that this kind of code will eventually become idomatic
> Swift and soon all the good 3rd party libraries will be written like this?
> If yes, that means that Swift has failed as a language, people really
> wanted another Javascript. If not, what's the harm? Maybe eventually people
> doing this will realize that "proper" Swift is better. Or not.
>

Unless DynamicLookup is used to circumvent every compiler warning or errors
thrown at you by the language because your design is unsound. Something
like "ho, yeah swift generics and protocols aren't really working fine
together for your case, but just make everything DynamicLookupable and
you'll be all set". Or "This JSON document has a really complex schema.
Let's just not specify anything, and call the fields like this, you won't
even feel any difference anyway".

The more i think about this proposal, the less i actually understand its
purpose.

1_ From what i understood from this discussion (please correct me if i'm
wrong) python code is already callable from swift right now, without any
modification to the compiler, but then the syntax to *some* very generic
python function would just not be really pretty. If it's just library
calls, we could just wrap those calls into pretty functions for our needs,
but then :
2_ There are some python developers that hate python and would like to jump
ship and start developing in Swift because of ? ( here, i suppose things
like code completion, or anything "compile time", because that's the only
part where swift would have an edge against python regarding data libs,
since python is just glue code around high performance C). And we want to
make it pretty for them.
3_ So let's make swift more dynamic and disable compile-time checks for
what those guys are going to use ??

Which means we're adding dynamic , runtime checks to a compile-time checked
language, to help people moving out of a dynamic language...  There's
something in that logic that i fail to understand. Once again, if i can
only bring one useful personal experience, people in my field (regular
server-side development) are moving away from python to go. And believe me
the reason has very little to do with syntax or power in the type system
and more with good concurrency, fantastic compile time, fantastic stdlib,
and "good enough" syntax for the general cases.




>
> Right now there are a lot of people writting Swift in an Objective-C
> style. e.g. using classes when they should have used structs, using
> inheritance when they should have used protocols. Should we add some
> language feature to stop them?
>







>
>
> ___
> 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: Introduce User-defined "Dynamic Member Lookup" Types

[Ben Rimmington via swift-evolution]

> Chris Lattner wrote:
> 
>   let np = Python.import("numpy")
>   let b = np^.array^([6, 7, 8])
>   let y =  np^.arange^(24)^.reshape^(2, 3, 4)
>   
>   let a = np^.ones^(3, dtype: np^.int32)
>   let b = np^.linspace^(0, pi, 3)
>   let c = a+^b
>   let d = np^.exp^(c)

You could require `throws` on `subscript(dynamicMember:)` APIs.

"Throwing Properties and Subscripts proposal by brentdax"


let np = Python.import("numpy")
let x = try! np.array([6, 7, 8])
let y = try! np.arange(24).reshape(2, 3, 4)

let a = try! np.ones(3, dtype: np.int32)
let b = try! np.linspace(0, pi, 3)
let c = try! a+b
let d = try! np.exp(c)

If you allow dynamic member lookup on stdlib types:

Double.pi.significant
 ^
ERROR: subscript can throw, but it is not marked with 'try'
NOTE: did you mean 'significand'?

An implementation could fail by throwing an error or returning `nil`.
For example, JSValue/JSON member lookup could allow optional chaining.
But trying to invoke a non-callable JSValue could throw a TypeError.

-- Ben

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

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

[Nick Keets via swift-evolution]

On Sun, Dec 3, 2017 at 10:16 PM, Matthew Johnson via swift-evolution <
swift-evolution@swift.org> wrote:

>
> Some people are big fans of dynamic behavior and this feature will make it
> much easier to write code in that style.  They will do it without feeling
> malicious or considering this to be abusive, considering it to be a
> legitimate style preference.  I wouldn’t be surprised to see people develop
> mixins that implement the subscript using mirror and other future
> reflection capabilities without considering that to be abusive (I would
> almost be surprised if this *didn’t* happen).  Requiring some kind of
> usage site annotation would both discourage this and help anyone who walks
> into a such a code base to understand what is going on.
>


I really don't understand this fear of metamorphosis. People could also be
using emoji for all their variables. So what? Let them do it!

Are you afraid that this kind of code will eventually become idomatic Swift
and soon all the good 3rd party libraries will be written like this? If
yes, that means that Swift has failed as a language, people really wanted
another Javascript. If not, what's the harm? Maybe eventually people doing
this will realize that "proper" Swift is better. Or not.

Right now there are a lot of people writting Swift in an Objective-C style.
e.g. using classes when they should have used structs, using inheritance
when they should have used protocols. Should we add some language feature
to stop them?
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Wallacy via swift-evolution]

May the question is a little silly. But can this proposal be made on top of
property behaviors? ( or the inverse).


We already talk about *new kinds* of getters and setters, possibly new
sintaxes to call then... I don’t now, maybe I’m overlooking the problem,
but feels that , wherever we choose here should be userfull for other
things in the language.



Em seg, 4 de dez de 2017 às 06:42, Vincent Esche via swift-evolution <
swift-evolution@swift.org> escreveu:

> I think the argument basically is "let's not add another footgun" (because
>> the design of Swift , for example regarding null handling, is to have less
>> footguns than other languages). The fact that there are footguns in swift
>> isn't an argument for adding new ones.
>
>
> Couldn’t have said it better. This is what it all boils down to.
>
> On Mon, Dec 4, 2017 at 12:16 AM, Benjamin G via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>>
>> On Sun, Dec 3, 2017 at 8:26 PM, Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp  wrote:
>>> >
>>> >> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>> >>
>>> >> That’s a good principle.  However, a dynamic member lookup is just a
>>> member lookup.  By that principle, it should look like a member lookup :-)
>>> >>
>>> >> Further, I incorporated some of the conversation with Matthew into
>>> the proposal, showing how adding even a single sigil to dynamic member
>>> lookup to distinguish it is problematic:
>>> >>
>>> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#increasing-visibility-of-dynamic-member-lookups
>>> >>
>>> >> Further, adding something like .dynamic would completely undermind
>>> the proposal.  You can already write:
>>> >>
>>> >>  x.get(“foo”).get(“bar”)
>>> >>
>>> >> having to write:
>>> >>
>>> >>  x.dynamic.foo.dynamic.bar
>>> >>
>>> >> has no point.
>>> >
>>> > This example shows what many on this list don't believe: that any
>>> Swift method or member access can fail. If the return value of this "get"
>>> method is an IUO, or not an Optional at all, and doesn't throw, then the
>>> expression would have to fail hard if "foo" didn't resolve to something
>>> meaningful.
>>> >
>>> > The most common argument against this proposal is that someone could
>>> make an API using Dynamic Member Lookup that could fail even though it is
>>> not apparent to the caller. But, as we see in the example, this is just as
>>> possible today.
>>>
>>> Correct.  The argument also fails to recognize that (when bridging to a
>>> dynamic language):
>>>
>>> x+y
>>>
>>> Is a completely dynamic method call which can fail (or return IUO), as
>>> is:
>>>
>>> x[i]
>>>
>>> And that this is true with no changes to Swift.  The claim that such a
>>> thing is counter to the design of Swift is completely perplexing to me.
>>>
>>
>> I think the argument basically is "let's not add another footgun"
>> (because the design of Swift , for example regarding null handling, is to
>> have less footguns than other languages). The fact that there are footguns
>> in swift isn't an argument for adding new ones.
>>
>>
>>
>>>
>>> -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/swift-evolution

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

[David Hart via swift-evolution]

> On 4 Dec 2017, at 10:42, Vincent Esche via swift-evolution 
>  wrote:
> 
> I think the argument basically is "let's not add another footgun" (because 
> the design of Swift , for example regarding null handling, is to have less 
> footguns than other languages). The fact that there are footguns in swift 
> isn't an argument for adding new ones.
> 
> Couldn’t have said it better. This is what it all boils down to.

I would definitely not go as far as calling this proposal a language footgun.

> On Mon, Dec 4, 2017 at 12:16 AM, Benjamin G via swift-evolution 
> > wrote:
> 
> 
> On Sun, Dec 3, 2017 at 8:26 PM, Chris Lattner via swift-evolution 
> > wrote:
> On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp  > wrote:
> >
> >> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution 
> >> > wrote:
> >>
> >> That’s a good principle.  However, a dynamic member lookup is just a 
> >> member lookup.  By that principle, it should look like a member lookup :-)
> >>
> >> Further, I incorporated some of the conversation with Matthew into the 
> >> proposal, showing how adding even a single sigil to dynamic member lookup 
> >> to distinguish it is problematic:
> >> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#increasing-visibility-of-dynamic-member-lookups
> >>  
> >> 
> >>
> >> Further, adding something like .dynamic would completely undermind the 
> >> proposal.  You can already write:
> >>
> >>  x.get(“foo”).get(“bar”)
> >>
> >> having to write:
> >>
> >>  x.dynamic.foo.dynamic.bar
> >>
> >> has no point.
> >
> > This example shows what many on this list don't believe: that any Swift 
> > method or member access can fail. If the return value of this "get" method 
> > is an IUO, or not an Optional at all, and doesn't throw, then the 
> > expression would have to fail hard if "foo" didn't resolve to something 
> > meaningful.
> >
> > The most common argument against this proposal is that someone could make 
> > an API using Dynamic Member Lookup that could fail even though it is not 
> > apparent to the caller. But, as we see in the example, this is just as 
> > possible today.
> 
> Correct.  The argument also fails to recognize that (when bridging to a 
> dynamic language):
> 
> x+y
> 
> Is a completely dynamic method call which can fail (or return IUO), as is:
> 
> x[i]
> 
> And that this is true with no changes to Swift.  The claim that such a thing 
> is counter to the design of Swift is completely perplexing to me.
> 
> I think the argument basically is "let's not add another footgun" (because 
> the design of Swift , for example regarding null handling, is to have less 
> footguns than other languages). The fact that there are footguns in swift 
> isn't an argument for adding new ones.
> 
>  
> 
> -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/swift-evolution

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

[Vincent Esche via swift-evolution]

>
> I think the argument basically is "let's not add another footgun" (because
> the design of Swift , for example regarding null handling, is to have less
> footguns than other languages). The fact that there are footguns in swift
> isn't an argument for adding new ones.


Couldn’t have said it better. This is what it all boils down to.

On Mon, Dec 4, 2017 at 12:16 AM, Benjamin G via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Sun, Dec 3, 2017 at 8:26 PM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> On Dec 3, 2017, at 11:03 AM, Magnus Ahltorp  wrote:
>> >
>> >> 4 Dec. 2017 02:40 Chris Lattner via swift-evolution <
>> swift-evolution@swift.org> wrote:
>> >>
>> >> That’s a good principle.  However, a dynamic member lookup is just a
>> member lookup.  By that principle, it should look like a member lookup :-)
>> >>
>> >> Further, I incorporated some of the conversation with Matthew into the
>> proposal, showing how adding even a single sigil to dynamic member lookup
>> to distinguish it is problematic:
>> >> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae
>> 5438#increasing-visibility-of-dynamic-member-lookups
>> >>
>> >> Further, adding something like .dynamic would completely undermind the
>> proposal.  You can already write:
>> >>
>> >>  x.get(“foo”).get(“bar”)
>> >>
>> >> having to write:
>> >>
>> >>  x.dynamic.foo.dynamic.bar
>> >>
>> >> has no point.
>> >
>> > This example shows what many on this list don't believe: that any Swift
>> method or member access can fail. If the return value of this "get" method
>> is an IUO, or not an Optional at all, and doesn't throw, then the
>> expression would have to fail hard if "foo" didn't resolve to something
>> meaningful.
>> >
>> > The most common argument against this proposal is that someone could
>> make an API using Dynamic Member Lookup that could fail even though it is
>> not apparent to the caller. But, as we see in the example, this is just as
>> possible today.
>>
>> Correct.  The argument also fails to recognize that (when bridging to a
>> dynamic language):
>>
>> x+y
>>
>> Is a completely dynamic method call which can fail (or return IUO), as is:
>>
>> x[i]
>>
>> And that this is true with no changes to Swift.  The claim that such a
>> thing is counter to the design of Swift is completely perplexing to me.
>>
>
> I think the argument basically is "let's not add another footgun" (because
> the design of Swift , for example regarding null handling, is to have less
> footguns than other languages). The fact that there are footguns in swift
> isn't an argument for adding new ones.
>
>
>
>>
>> -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