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

[Chris Lattner via swift-evolution]

> On Dec 20, 2017, at 1:36 PM, Chris Lattner via swift-evolution 
>  wrote:
> 
>> On Dec 19, 2017, at 11:26 PM, Douglas Gregor  wrote:
>> 
>>> Beyond that, they are small extensions with low complexity, scale to 
>>> supporting many different dynamic languages over time,  require a level of 
>>> engineering effort that is plausible to be built, and do not require some 
>>> sort of "executive buy in” from the Python community.
>> 
>> Here’s an alternative proposal that provides a better development 
>> experience: write a wrapper generator, in Python, that maps a Python 
>> module’s interfaces to Swift, and provide small tie-ins to the compiler to 
>> make it fit well. Take the example from the DynamicMemberLookup proposal:
> 
> Doug and I and the rest of the core team discussed this today, and agreed 
> that the foreign class idea proposed isn’t necessary - the majority of the 
> value is being provided by the generated wrapper code, and that wrapper code 
> composes on top of the existing Python prototype with no additional language 
> features.  Given that, we’re not pursuing the ‘foreign class’ idea.
> 
> That said, if wrappers are sufficient to solve the problem, that could 
> eliminate the need for the other two proposals entirely.  I’m going to 
> explore this a bit to understand the limitations and advantages of this 
> approach and will get back to this list (in a new thread) in a couple weeks.

One other thing: I believe that there was agreement in the meeting that 
generating a good code completion experience can work with any of these 
proposals, through reasonable extensions to SourceKit.  Doing a good job of 
code completion for python APIs involves doing some heuristic control flow 
analysis stuff that doesn’t already exist in the existing Swift toolchain 
anyway.  I believe we’re now focused on whether wrappers can be “good enough” 
to solve the problem without other language extensions.

-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

[Chris Lattner via swift-evolution]

> On Dec 19, 2017, at 11:26 PM, Douglas Gregor  wrote:
> 
>>  Beyond that, they are small extensions with low complexity, scale to 
>> supporting many different dynamic languages over time,  require a level of 
>> engineering effort that is plausible to be built, and do not require some 
>> sort of "executive buy in” from the Python community.
> 
> Here’s an alternative proposal that provides a better development experience: 
> write a wrapper generator, in Python, that maps a Python module’s interfaces 
> to Swift, and provide small tie-ins to the compiler to make it fit well. Take 
> the example from the DynamicMemberLookup proposal:

Doug and I and the rest of the core team discussed this today, and agreed that 
the foreign class idea proposed isn’t necessary - the majority of the value is 
being provided by the generated wrapper code, and that wrapper code composes on 
top of the existing Python prototype with no additional language features.  
Given that, we’re not pursuing the ‘foreign class’ idea.

That said, if wrappers are sufficient to solve the problem, that could 
eliminate the need for the other two proposals entirely.  I’m going to explore 
this a bit to understand the limitations and advantages of this approach and 
will get back to this list (in a new thread) in a couple weeks.

-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

[Douglas Gregor via swift-evolution]

> On Dec 1, 2017, at 9:37 AM, Chris Lattner  wrote:
> 
> On Dec 1, 2017, at 12:26 AM, Douglas Gregor  > wrote:
>>> On Nov 30, 2017, at 10:05 PM, Chris Lattner >> > wrote:
>>> Hi Doug,
>>> 
>>> Thank you for the detailed email.  I have been traveling today, so I 
>>> haven’t had a chance to respond until now.  I haven’t read the down-thread 
>>> emails, so I apologize if any of this was already discussed:
>>> 
 I think better interoperability with Python (and other OO languages in 
 widespread use) is a good goal, and I agree that the implementation of the 
 feature described is straight-forward and not terribly invasive in the 
 compiler.
>>> 
>>> Fantastic, I’m really pleased to hear that!  I only care about solving the 
>>> problem, so if we can find a good technical solution to the problems than 
>>> I’ll be happy.
> 
> After thinking about your email a bit more, I think I might understand the 
> disconnect we’re having.  I think we have different versions in mind of what 
> “success” looks like:
> 
> I believe your view is that people start using Python APIs from their Swift 
> code, but gradually add type annotations (either inline or in a sidecar 
> database) to make those APIs progressively more Swifty.  New features will be 
> added to Python (its type system, compilers, databases for common APIs, etc) 
> to improve this interoperability, along the lines of what we’ve done for 
> Objective-C over the years.  Fast forward several years, and large Python 
> libraries would be nice to use from Swift - perhaps nicer than they are to 
> use from Python itself.  This view aligns with what happened with Objective-C 
> <-> Swift interoperability.
> 
> In contrast, I’m specifically interested in developers in certain large 
> domains (e.g. data science and ML) which are “forced” to use Python because 
> that is where all the libraries are.  I have spoken to many of these sorts of 
> people, and a large number of them really *dislike* using Python for all the 
> obvious reasons (including the tooling issues you point out).  My view of 
> success is that we allow them to write all of *their code* in Swift, which 
> will lead to a massive quality of life benefit for these frustrated people.  
> You’re right that they will still chaff when using imported Python APIs 
> (which don’t feel “swifty” for LOTS of reasons - e.g. method naming and 
> design patterns), but my view is that this will provide incentive for these 
> people to provide a proper Swift implementation for these libraries over time.
> 
> In short, your end game is a pervasively intertwined Swift/Python world (like 
> ObjC and Swift are).  My view is that Swift holds Python at arm's length, and 
> wins over the hearts and minds of developers, leading to new Swift APIs 
> designed for Swift.

That’s not the end game I’m looking at. I’d rather make it feasible to generate 
Swift wrappers for Python libraries that fit well into Swift’s existing 
machinery. The complexity goes outside the compiler, with small extralinguistic 
tie-ins to make it work well.

> I’m not sure if you agree with that portrayal of your position, and if not, 
> I’m sorry and will try to understand another way.  However, if I’m close, 
> then I have several concerns about that vision and don’t believe the end-game 
> is achievable or better than what I’m proposing.  Consider:
> 
> - I don’t think there will be a lot of success getting people who *actually 
> love* Python to use Swift, unless there is already an extrinsic reason for 
> them to use it.
> - Type hints are not widely used in Python, and there are believable reasons 
> that they won’t ever be.  Because they are specifically poorly suited for 
> libraries, their use seems to be in “user’s own code” - but my proposal 
> solves this already!  See below for examples.
> - Even if type hints were widely adopted, it would require massive extensions 
> to them and to Python to make them be "good enough” to provide value for the 
> things you’re envisioning.  Analogs to instancetype, objc generics, lots of 
> the C macros, and many of the other things we’ve added to ObjC would have to 
> be added.
> - The Python community has no reason to do this work for the Swift community, 
> or accept changes to Python that are required to make this actually great.
> - Beyond the core type system, the Python and Objective-C languages work 
> extremely differently in other ways (e.g. lack of umbrella headers making 
> AnyObject-style dispatch questionable).
> - Even with those annotations and all the work, the APIs we’d end up with are 
> not going to be good Swift APIs.  I don’t think that “renamification” and 
> "IUO audits" would ever actually happen in practice, for example.
> - I believe the engineering effort required to implement this vision is so 
> massive (including the changes to Swift, 

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

[Chris Lattner via swift-evolution]

> On Dec 12, 2017, at 9:26 AM, C. Keith Ray  wrote:
> 
> in https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 
> 
> 
> there is this statement:
> 
> "For this reason, the compiler only permits conformance of this protocol on 
> the original type definition, not extensions"
> 
> and this example:
> 
> extension JSON : DynamicMemberLookupProtocol {
> 
> 
> Contradictory?

Yes, thanks for catching that, I fixed the proposal to not describe these as 
extensions.

> Calling Java from C is done like the following, how would one do it in Swift 
> using this proposal?

I’m not sure what your question is.  I’m not an expert in JNI interop.

-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

[Letanyan Arumugam via swift-evolution]

> On 12 Dec 2017, at 19:27, C. Keith Ray via swift-evolution 
>  wrote:
> 
> in https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438 
> 
> 
> there is this statement:
> 
> "For this reason, the compiler only permits conformance of this protocol on 
> the original type definition, not extensions"
> 
> and this example:
> 
> extension JSON : DynamicMemberLookupProtocol {
> 
> 
> Contradictory?
> 
I think this is just an oversight after it was changed that this protocol could 
not conform on extensions.

> 
> Also...
> 
> Calling Java from C is done like the following, how would one do it in Swift 
> using this proposal?
> 
> ( Example from 
> https://www.ibm.com/developerworks/java/tutorials/j-jni/j-jni.html 
>  )
> 
> Java code:
> 
>   public class Sample2
>   {
> public static int intMethod(int n) {
> return n*n;
> }
>  
> public static boolean booleanMethod(boolean bool) {
>  return !bool;
> }
>   }
> 
> C Code:
> 
> #include 
> 
> #ifdef _WIN32
> #define PATH_SEPARATOR ';'
> #else
> #define PATH_SEPARATOR ':'
> #endif
> int main()
> {
>   JavaVMOption options[1];
>   JNIEnv *env;
>   JavaVM *jvm;
>   JavaVMInitArgs vm_args;
>   long status;
>   jclass cls;
>   jmethodID mid;
>   jint square;
>   jboolean not;
> 
>   options[0].optionString = "-Djava.class.path=.";
>   memset(_args, 0, sizeof(vm_args));
>   vm_args.version = JNI_VERSION_1_2;
>   vm_args.nOptions = 1;
>   vm_args.options = options;
>   status = JNI_CreateJavaVM(, (void**), _args);
> 
>   if (status != JNI_ERR)
>   {
> cls = (*env)->FindClass(env, "Sample2");
> 
> if (cls !=0)
> { 
>   mid = (*env)->GetStaticMethodID(env, cls, "intMethod", "(I)I");
>   
>   if (mid !=0)
>   { 
> square = (*env)->CallStaticIntMethod(env, cls, mid, 5);
> printf("Result of intMethod: %d\n", square);
>   }
>   
>   mid = (*env)->GetStaticMethodID(env, cls, "booleanMethod", "(Z)Z");
>   
>   if (mid !=0)
>   { 
>  not = (*env)->CallStaticBooleanMethod(env, cls, mid, 1);
>  printf("Result of booleanMethod: %d\n", not);
>   }
>}
>(*jvm)->DestroyJavaVM(jvm);
>return 0;
>   }
>   else
> return -1;
> }
> 

I think this should be up to whoever implements the Java wrapper. This proposal 
doesn’t specifically address the implementation of specific language interop’s. 
It just gives the writer a way to give their implementation a nice syntactic 
view in the language.

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

in https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438

there is this statement:

"For this reason, the compiler only permits conformance of this protocol on the 
original type definition, not extensions"

and this example:

extension JSON : DynamicMemberLookupProtocol {


Contradictory?


Also...

Calling Java from C is done like the following, how would one do it in Swift 
using this proposal?

( Example from 
https://www.ibm.com/developerworks/java/tutorials/j-jni/j-jni.html )

Java code:

  public class Sample2
  {
public static int intMethod(int n) {
return n*n;
}
 
public static boolean booleanMethod(boolean bool) {
 return !bool;
}
  }

C Code:

#include 

#ifdef _WIN32
#define PATH_SEPARATOR ';'
#else
#define PATH_SEPARATOR ':'
#endif
int main()
{
  JavaVMOption options[1];
  JNIEnv *env;
  JavaVM *jvm;
  JavaVMInitArgs vm_args;
  long status;
  jclass cls;
  jmethodID mid;
  jint square;
  jboolean not;

  options[0].optionString = "-Djava.class.path=.";
  memset(_args, 0, sizeof(vm_args));
  vm_args.version = JNI_VERSION_1_2;
  vm_args.nOptions = 1;
  vm_args.options = options;
  status = JNI_CreateJavaVM(, (void**), _args);

  if (status != JNI_ERR)
  {
cls = (*env)->FindClass(env, "Sample2");

if (cls !=0)
{ 
  mid = (*env)->GetStaticMethodID(env, cls, "intMethod", "(I)I");
  
  if (mid !=0)
  { 
square = (*env)->CallStaticIntMethod(env, cls, mid, 5);
printf("Result of intMethod: %d\n", square);
  }
  
  mid = (*env)->GetStaticMethodID(env, cls, "booleanMethod", "(Z)Z");
  
  if (mid !=0)
  { 
 not = (*env)->CallStaticBooleanMethod(env, cls, mid, 1);
 printf("Result of booleanMethod: %d\n", not);
  }
   }
   (*jvm)->DestroyJavaVM(jvm);
   return 0;
  }
  else
return -1;
}


___
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

[Steven Brunwasser via swift-evolution]

> On Dec 10, 2017, at 13:01, Chris Lattner via swift-evolution 
>  wrote:
> 
>>> On Dec 10, 2017, at 6:00 AM, Brent Royal-Gordon via swift-evolution 
>>>  wrote:
>>> 
>>> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution 
>>>  wrote:
>>> 
 On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser  
 wrote:
 Just wanted to give my 2¢
 
 ¢
 I don’t like empty protocols—they feel like an abuse of the feature.
>>> 
>>> As has been discussed here before, protocols aren’t about bags of syntax 
>>> but rather about semantics. Empty protocols are explicitly a demonstration 
>>> of this settled principle and are very much consistent with the direction 
>>> of Swift.
>> 
>> 
>> I also think it should be an attribute.
>> 
>> The last time I said this, I pointed out that this was a protocol which:
>> 
>> 1. Has no formal members,
>> 2. But imposes informal requirements enforced by the compiler,
>> 3. Permits and uses arbitrary overloads, and
>> 4. Cannot be usefully used in a generic context or as a type constraint,
>> 
>> None of which are true of ordinary protocols. Since then, we have added:
>> 
>> 5. Can only be conformed to in the main declaration.
>> 
>> This is looking less like a protocol by the day. The square-peg grooves in 
>> the round hole are getting deeper and more splintery with every revision.
> 
> Hi Brent,
> 
> This approach definitely could work.  I added it to the alternatives section 
> with a breakdown of why I don’t think it’s the right direction:
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#make-this-be-a-attribute-on-a-type-instead-of-a-protocol-conformance

I think the protocol vs attribute debate is more about what it means to be an 
attribute. I personally see attributes as eventually becoming a more extensible 
meta-programming tool, but that might not be the community’s consensus.

Assuming that attributes are for meta-programming, this would make more sense 
as an attribute, since its a tool for dynamically resolving undefined symbols 
at compile-time.

- Steve___
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 10, 2017, at 10:04 AM, Paul Cantrell  wrote:
>> This is looking less like a protocol by the day. The square-peg grooves in 
>> the round hole are getting deeper and more splintery with every revision.
> 
> The flavor of DynamicMemberLookupProtocol with an explicit member requirement 
> sure does _read_ nicely! The fact that Chris left it present but commented 
> out in the proposal suggests that expressing it that way has some intuitive / 
> communicative value.
> 
> This section laying out the reasons why it doesn’t work:
> 
> 
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#declare-an-explicit-subscript-requirement
>  
> 
> 
> …reads like a todo list for rounding out protocols and generics.
> 
> So, Chris, question: in the future, maybe circa Swift 6 or 7, is it likely 
> that generalized existentials + some sort of more robust handling of 
> “mutating” in protocols would make the explicit member requirement on 
> DynamicMemberLookupProtocol actually work?

It is possible.   I’m not the best expert on the generics system, but I can’t 
imagine that it would be a priority in the near term.

-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

[Chris Lattner via swift-evolution]

On Dec 10, 2017, at 12:22 PM, Xiaodi Wu via swift-evolution 
 wrote:
> The last time I said this, I pointed out that this was a protocol which:
> 
> 1. Has no formal members,
> 2. But imposes informal requirements enforced by the compiler,
> 3. Permits and uses arbitrary overloads, and
> 4. Cannot be usefully used in a generic context or as a type constraint,
> 
> None of which are true of ordinary protocols. Since then, we have added:
> 
> 5. Can only be conformed to in the main declaration.
> 
> This is looking less like a protocol by the day. The square-peg grooves in 
> the round hole are getting deeper and more splintery with every revision.
> 
> Synthesized conformances cannot be declared in extensions either. If you'd 
> like, you could consider that this protocol is one for which the compiler 
> synthesizes an infinite number of members.
> 
> I would like to see (4) addressed: a complete implementation should allow me 
> to call any member on a type T in a generic context where T : 
> DynamicMemberLookupProtocol, which I kind of assumed that this proposal would 
> eventually permit.

The technical problem with this is that there are no witnesses in the protocol 
witness table - either for the subscripts or for the conceptual associated 
types of the index and return value of the subscript.

-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

[Chris Lattner via swift-evolution]

> On Dec 10, 2017, at 6:00 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser > > wrote:
>> Just wanted to give my 2¢
>> 
>> ¢
>> I don’t like empty protocols—they feel like an abuse of the feature.
>> 
>> As has been discussed here before, protocols aren’t about bags of syntax but 
>> rather about semantics. Empty protocols are explicitly a demonstration of 
>> this settled principle and are very much consistent with the direction of 
>> Swift.
> 
> 
> I also think it should be an attribute.
> 
> The last time I said this, I pointed out that this was a protocol which:
> 
> 1. Has no formal members,
> 2. But imposes informal requirements enforced by the compiler,
> 3. Permits and uses arbitrary overloads, and
> 4. Cannot be usefully used in a generic context or as a type constraint,
> 
> None of which are true of ordinary protocols. Since then, we have added:
> 
> 5. Can only be conformed to in the main declaration.
> 
> This is looking less like a protocol by the day. The square-peg grooves in 
> the round hole are getting deeper and more splintery with every revision.

Hi Brent,

This approach definitely could work.  I added it to the alternatives section 
with a breakdown of why I don’t think it’s the right direction:
https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#make-this-be-a-attribute-on-a-type-instead-of-a-protocol-conformance
 


-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

[Xiaodi Wu via swift-evolution]

On Sun, Dec 10, 2017 at 7:59 AM, Brent Royal-Gordon 
wrote:

> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser 
> wrote:
>
>> Just wanted to give my 2¢
>>
>> ¢
>> I don’t like empty protocols—they feel like an abuse of the feature.
>>
>
> As has been discussed here before, protocols aren’t about bags of syntax
> but rather about semantics. Empty protocols are explicitly a demonstration
> of this settled principle and are very much consistent with the direction
> of Swift.
>
>
> I also think it should be an attribute.
>
> The last time I said this, I pointed out that this was a protocol which:
>
> 1. Has no formal members,
> 2. But imposes informal requirements enforced by the compiler,
> 3. Permits and uses arbitrary overloads, and
> 4. Cannot be usefully used in a generic context or as a type constraint,
>
> None of which are true of ordinary protocols. Since then, we have added:
>
> 5. Can only be conformed to in the main declaration.
>
> This is looking less like a protocol by the day. The square-peg grooves in
> the round hole are getting deeper and more splintery with every revision.
>

Synthesized conformances cannot be declared in extensions either. If you'd
like, you could consider that this protocol is one for which the compiler
synthesizes an infinite number of members.

I would like to see (4) addressed: a complete implementation should allow
me to call any member on a type T in a generic context where T :
DynamicMemberLookupProtocol, which I kind of assumed that this proposal
would eventually permit.
___
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 10, 2017, at 8:00 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
> None of which are true of ordinary protocols. Since then, we have added:
> 
> 5. Can only be conformed to in the main declaration.

This is the main thing that made me think Letanyan's suggestion of an attribute 
might make more sense for this than just a normal protocol. I'm not really a 
fan of bifurcating the semantics with an attribute denoting "safe"/"unsafe" 
versions of the protocol. But if this restriction is accepted (which I think it 
must be in order to avoid some legitimate concerns), this is something that 
would be unique to this protocol that no other protocol has had to adhere to. 
If this type of requirement isn't made available more generally to protocols, 
then this would be a very special case that complicates the definition of what 
a protocol is. I'm curious to hear Chris's thoughts on Paul's feedback.___
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

[Paul Cantrell via swift-evolution]

> On Dec 10, 2017, at 8:00 AM, Brent Royal-Gordon via swift-evolution 
>  wrote:
> 
>> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution 
>> > wrote:
>> 
>> On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser > > wrote:
>> Just wanted to give my 2¢
>> 
>> ¢
>> I don’t like empty protocols—they feel like an abuse of the feature.
>> 
>> As has been discussed here before, protocols aren’t about bags of syntax but 
>> rather about semantics. Empty protocols are explicitly a demonstration of 
>> this settled principle and are very much consistent with the direction of 
>> Swift.
> 
> 
> I also think it should be an attribute.
> 
> The last time I said this, I pointed out that this was a protocol which:
> 
> 1. Has no formal members,
> 2. But imposes informal requirements enforced by the compiler,
> 3. Permits and uses arbitrary overloads, and
> 4. Cannot be usefully used in a generic context or as a type constraint,
> 
> None of which are true of ordinary protocols. Since then, we have added:
> 
> 5. Can only be conformed to in the main declaration.
> 
> This is looking less like a protocol by the day. The square-peg grooves in 
> the round hole are getting deeper and more splintery with every revision.

The flavor of DynamicMemberLookupProtocol with an explicit member requirement 
sure does _read_ nicely! The fact that Chris left it present but commented out 
in the proposal suggests that expressing it that way has some intuitive / 
communicative value.

This section laying out the reasons why it doesn’t work:


https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#declare-an-explicit-subscript-requirement
 


…reads like a todo list for rounding out protocols and generics.

So, Chris, question: in the future, maybe circa Swift 6 or 7, is it likely that 
generalized existentials + some sort of more robust handling of “mutating” in 
protocols would make the explicit member requirement on 
DynamicMemberLookupProtocol actually work?

If that seems likely, it would make sense to keep it an empty protocol now with 
the expectation that the language will catch up and the member requirement can 
be made explicit.

If that isn’t likely — if we expect that the member requirement will never 
really work — then my gut reaction is that Brent has a point.

Per Xiaodi, empty protocols per se aren’t a problem; Brent’s #1 and #2 don’t 
bother me much. But his #5 suggests this is deeply un-protocol-like, and if his 
#3 and #4 are never addressed by the compiler, then an attribute really is 
worth considering.

I guess the question boils down to whether this protocol behaves like a type, 
where implementing the protocol expresses an “is-a” relationship that makes 
semantic and intuitive sense, or whether it behaves more like a compiler flag 
that doesn’t express any useful type relationship.

Cheers, P

___
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

[Brent Royal-Gordon via swift-evolution]

> On Dec 9, 2017, at 10:32 AM, Xiaodi Wu via swift-evolution 
>  wrote:
> 
> On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser  > wrote:
> Just wanted to give my 2¢
> 
> ¢
> I don’t like empty protocols—they feel like an abuse of the feature.
> 
> As has been discussed here before, protocols aren’t about bags of syntax but 
> rather about semantics. Empty protocols are explicitly a demonstration of 
> this settled principle and are very much consistent with the direction of 
> Swift.


I also think it should be an attribute.

The last time I said this, I pointed out that this was a protocol which:

1. Has no formal members,
2. But imposes informal requirements enforced by the compiler,
3. Permits and uses arbitrary overloads, and
4. Cannot be usefully used in a generic context or as a type constraint,

None of which are true of ordinary protocols. Since then, we have added:

5. Can only be conformed to in the main declaration.

This is looking less like a protocol by the day. The square-peg grooves in the 
round hole are getting deeper and more splintery with every revision.

-- 
Brent Royal-Gordon
Architechies

___
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

[Xiaodi Wu via swift-evolution]

On Sat, Dec 9, 2017 at 11:20 Steven Brunwasser 
wrote:

> Just wanted to give my 2¢
>
> ¢
> I don’t like empty protocols—they feel like an abuse of the feature.
>

As has been discussed here before, protocols aren’t about bags of syntax
but rather about semantics. Empty protocols are explicitly a demonstration
of this settled principle and are very much consistent with the direction
of Swift.

I think attributes are the right way to go, since this proposal is about
> enabling syntactic sugar for types which can’t yet be described in the
> language as-is. This prevents retroactive conformance on preexisting types,
> which some have raised as a concern.
>
> ¢
> I think the discussion about whether or not implementations should throw,
> return optional, or be implicitly unwrapped is a larger discussion on its
> own, and should probably be a separate proposal to steer the language
> towards a more well defined convention. That being said, I’m of the opinion
> that they should always return an implicitly unwrapped value. The precedent
> is already in the language, it allows for cleaner syntax while also
> explicitly stating “hey, just so you know, I might not work, so be careful,
> ok?”, and callers can choose to be more cautious by explicitly using the ?
> operator.
>
> That is all,
> - Steve
>
> On Dec 8, 2017, at 16:34, Xiaodi Wu via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> See below.
>>
>> On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Apologies, I may have misunderstood you. What I wanted to say is that I
>> see no problem allowing "dangerous" stuff that may be abused.
>>
>>
>> You see no problem with danger and abuse?
>>
>> I guess we have differing philosophies...
>>
>> https://developer.apple.com/swift/ states:
>>
>> “Swift eliminates entire classes of unsafe code.”
>>
>> Lets keep it that way.
>>
>> I’m all for this proposal if it can be tweaked to where any of the
>> dangerous invocations contain the word, “Unsafe”, or equivalent.
>>
>
> Again, in Swift, “safety” means something very specific. Trapping at
> runtime is safe; in fact, trapping at runtime is *precisely the means by
> which safety is achieved* in the case of integer overflow and array
> indexing. This proposal introduces nothing that is unsafe.
>
> ~Jon
>>
>>
>> ___
>> 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

[Paul Cantrell via swift-evolution]

I’m not at all a fan of _forcing_ IUOs. Depending on the application, return 
types of Self!, Self?, always-succeeds Self, Self + throws, or Self + 
fatalError could all be the best approach.

In Python and JS, where objects have a dictionary-like shape, IUOs make sense: 
code can test for member presence when appropriate, while keeping general 
member access ergonomic.

In Ruby, where member lookup is fundamentally shaped more like a method call 
than a dictionary lookup, and where accessing a nonexistent member is a runtime 
error in the native language, then either throws or fatalError would be more 
appropriate.

I can imagine data-centric languages where traversing nonexistent members is 
typical and expected, either because the language has behavior like old-school 
Obj-C nil handling or because has create-on-traversal semantics. That behavior 
would be baked into to the shape of the APIs designed for the language. In that 
case, never-failing Self would be appropriate.

• • •

I like the Chris’s approach where LookupType is an associated type (or, if we 
go with the empty protocol, behaves like one). It handles all these 
possibilities nicely, and then some.

It gives implementors latitude to choose the appropriate approach, and thus 
places the burden the authors of language-specific bridges to make 
language-appropriate design choices — which is _exactly_ as it should be.

Per my earlier message, I am interested in making well-designed libraries work 
as beautifully as possible, not in beating the authors of ill-designed ones 
over the head! The latter is futile, and this is a quintessential example of 
where pursuing the latter undermines the former.

Cheers,

Paul

> On Dec 9, 2017, at 11:20 AM, Steven Brunwasser via swift-evolution 
>  wrote:
> 
> Just wanted to give my 2¢
> 
> ¢
> I don’t like empty protocols—they feel like an abuse of the feature. I think 
> attributes are the right way to go, since this proposal is about enabling 
> syntactic sugar for types which can’t yet be described in the language as-is. 
> This prevents retroactive conformance on preexisting types, which some have 
> raised as a concern.
> 
> ¢
> I think the discussion about whether or not implementations should throw, 
> return optional, or be implicitly unwrapped is a larger discussion on its 
> own, and should probably be a separate proposal to steer the language towards 
> a more well defined convention. That being said, I’m of the opinion that they 
> should always return an implicitly unwrapped value. The precedent is already 
> in the language, it allows for cleaner syntax while also explicitly stating 
> “hey, just so you know, I might not work, so be careful, ok?”, and callers 
> can choose to be more cautious by explicitly using the ? operator.
> 
> That is all,
> - Steve
> 
> On Dec 8, 2017, at 16:34, Xiaodi Wu via swift-evolution 
> > wrote:
> 
>> On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution 
>> > wrote:
>> See below.
>> 
>> On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution 
>> > wrote:
>> 
>>> Apologies, I may have misunderstood you. What I wanted to say is that I see 
>>> no problem allowing "dangerous" stuff that may be abused.
>> 
>> You see no problem with danger and abuse?
>> 
>> I guess we have differing philosophies...
>> 
>> https://developer.apple.com/swift/  
>> states:
>> 
>> “Swift eliminates entire classes of unsafe code.”
>> 
>> Lets keep it that way.
>> 
>> I’m all for this proposal if it can be tweaked to where any of the dangerous 
>> invocations contain the word, “Unsafe”, or equivalent.
>> 
>> Again, in Swift, “safety” means something very specific. Trapping at runtime 
>> is safe; in fact, trapping at runtime is *precisely the means by which 
>> safety is achieved* in the case of integer overflow and array indexing. This 
>> proposal introduces nothing that is unsafe.
>> 
>> ~Jon
>> 
>> 
>> ___
>> 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

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

[C. Keith Ray via swift-evolution]

I agree.

Instead of a magic protocol, think I'd rather see "@dynamic" used like "@objc" 
is today. Maybe only applicable to class declarations. 

Implicitly unwrapped sounds reasonable... need to think on that some more.

--
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 9, 2017, at 9:20 AM, Steven Brunwasser via swift-evolution 
>  wrote:
> 
> Just wanted to give my 2¢
> 
> ¢
> I don’t like empty protocols—they feel like an abuse of the feature. I think 
> attributes are the right way to go, since this proposal is about enabling 
> syntactic sugar for types which can’t yet be described in the language as-is. 
> This prevents retroactive conformance on preexisting types, which some have 
> raised as a concern.
> 
> ¢
> I think the discussion about whether or not implementations should throw, 
> return optional, or be implicitly unwrapped is a larger discussion on its 
> own, and should probably be a separate proposal to steer the language towards 
> a more well defined convention. That being said, I’m of the opinion that they 
> should always return an implicitly unwrapped value. The precedent is already 
> in the language, it allows for cleaner syntax while also explicitly stating 
> “hey, just so you know, I might not work, so be careful, ok?”, and callers 
> can choose to be more cautious by explicitly using the ? operator.
> 
> That is all,
> - Steve
> 
>> On Dec 8, 2017, at 16:34, Xiaodi Wu via swift-evolution 
>>  wrote:
>> 
>>> On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution 
>>>  wrote:
>>> See below.
>>> 
 On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution 
  wrote:
 
 Apologies, I may have misunderstood you. What I wanted to say is that I 
 see no problem allowing "dangerous" stuff that may be abused.
>>> 
>>> You see no problem with danger and abuse?
>>> 
>>> I guess we have differing philosophies...
>>> 
>>> https://developer.apple.com/swift/ states:
>>> 
>>> “Swift eliminates entire classes of unsafe code.”
>>> 
>>> Lets keep it that way.
>>> 
>>> I’m all for this proposal if it can be tweaked to where any of the 
>>> dangerous invocations contain the word, “Unsafe”, or equivalent.
>> 
>> Again, in Swift, “safety” means something very specific. Trapping at runtime 
>> is safe; in fact, trapping at runtime is *precisely the means by which 
>> safety is achieved* in the case of integer overflow and array indexing. This 
>> proposal introduces nothing that is unsafe.
>> 
>>> ~Jon
>>> 
>>> 
>>> ___
>>> 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

[Steven Brunwasser via swift-evolution]

Just wanted to give my 2¢

¢
I don’t like empty protocols—they feel like an abuse of the feature. I think 
attributes are the right way to go, since this proposal is about enabling 
syntactic sugar for types which can’t yet be described in the language as-is. 
This prevents retroactive conformance on preexisting types, which some have 
raised as a concern.

¢
I think the discussion about whether or not implementations should throw, 
return optional, or be implicitly unwrapped is a larger discussion on its own, 
and should probably be a separate proposal to steer the language towards a more 
well defined convention. That being said, I’m of the opinion that they should 
always return an implicitly unwrapped value. The precedent is already in the 
language, it allows for cleaner syntax while also explicitly stating “hey, just 
so you know, I might not work, so be careful, ok?”, and callers can choose to 
be more cautious by explicitly using the ? operator.

That is all,
- Steve

> On Dec 8, 2017, at 16:34, Xiaodi Wu via swift-evolution 
>  wrote:
> 
>> On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution 
>>  wrote:
>> See below.
>> 
>>> On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution 
>>>  wrote:
>>> 
>>> Apologies, I may have misunderstood you. What I wanted to say is that I see 
>>> no problem allowing "dangerous" stuff that may be abused.
>> 
>> You see no problem with danger and abuse?
>> 
>> I guess we have differing philosophies...
>> 
>> https://developer.apple.com/swift/ states:
>> 
>> “Swift eliminates entire classes of unsafe code.”
>> 
>> Lets keep it that way.
>> 
>> I’m all for this proposal if it can be tweaked to where any of the dangerous 
>> invocations contain the word, “Unsafe”, or equivalent.
> 
> Again, in Swift, “safety” means something very specific. Trapping at runtime 
> is safe; in fact, trapping at runtime is *precisely the means by which safety 
> is achieved* in the case of integer overflow and array indexing. This 
> proposal introduces nothing that is unsafe.
> 
>> ~Jon
>> 
>> 
>> ___
>> 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

[Xiaodi Wu via swift-evolution]

On Fri, Dec 8, 2017 at 18:08 Jon Gilbert via swift-evolution <
swift-evolution@swift.org> wrote:

> See below.
>
> On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Apologies, I may have misunderstood you. What I wanted to say is that I
> see no problem allowing "dangerous" stuff that may be abused.
>
>
> You see no problem with danger and abuse?
>
> I guess we have differing philosophies...
>
> https://developer.apple.com/swift/ states:
>
> “Swift eliminates entire classes of unsafe code.”
>
> Lets keep it that way.
>
> I’m all for this proposal if it can be tweaked to where any of the
> dangerous invocations contain the word, “Unsafe”, or equivalent.
>

Again, in Swift, “safety” means something very specific. Trapping at
runtime is safe; in fact, trapping at runtime is *precisely the means by
which safety is achieved* in the case of integer overflow and array
indexing. This proposal introduces nothing that is unsafe.

~Jon
>
>
> ___
> 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

[Letanyan Arumugam via swift-evolution]

> On 08 Dec 2017, at 18:14, Jean-Daniel  wrote:
> 
> 
> 
>> Le 8 déc. 2017 à 02:48, Letanyan Arumugam via swift-evolution 
>> > a écrit :
>> 
>> 
>> 
>>> On 07 Dec 2017, at 22:26, Chris Lattner >> > wrote:
>>> 
 
 On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam > wrote:
 
>>> fatalError shouldn’t be used excessively. API surface areas for these 
>>> types are going to be massive (infinite technically). I assume many 
>>> people are going to be writing a lot of code would these types and 
>>> calling many methods and properties which would all essentially have a 
>>> fatalError. Would you consider it good code if the majority of all your 
>>> types had methods defined with fatalError calls.
>>> 
>>> What is the basis for this claim? Probably the majority of standard 
>>> library methods check preconditions and trap on failure. That is how I 
>>> write my code as well.
>>> 
>> 
>> I’m talking specifically about fatalError not precondition. fatalError 
>> is something that goes out with production code while precondition is 
>> used for debugging. I think you would agree a shipped program that has 
>> many states of being unrecoverable is not a good design?
> 
> You are aware that Int traps on overflow and arrays trap on out of 
> bounds, right?
> 
 
 Were each of them not decided upon separately based on certain tradeoffs? 
 Arrays for speed and Int overflow because having the addition operator 
 return an optional would be too cumbersome? If these reasons were not so 
 influential would they still be designed to trap?
>>> 
>>> Yes, each of these decisions was carefully made.  
>>> 
>>> My point is that pretty much all code can fail at runtime, including 
>>> "something that goes out with production code”, because integers and arrays 
>>> are pervasive. I do not understand your claim that Swift APIs do not 
>>> generally fail at runtime.
>>> 
>>> -Chris
>> 
>> I’m just saying that we should try to avoid failure at runtime as much as we 
>> can whenever we can. We shouldn’t think it’s okay to add more reasons to 
>> fail at runtime because there’s already reasons to fail. We should be trying 
>> to reduce these. And even if this is impossible I think its always good to 
>> try.
> 
> Failure at runtime is an intrinsic property of dynamic languages. This 
> proposal does not explicitly specify what append when a lookup fails and let 
> the bridge take care of this. I don’t think forcing a model would be the 
> right way to introduce dynamic features in the language. With an open 
> proposal, time will tell us what is the best way to bridge dynamic language 
> and unfitted bridges/libraries will just be forgotten.
> 
> If having a dynamic bridge that trap on failure is an issue, just use one 
> that don’t. If dynamic code feel unsafe to you, you don’t use it and keep 
> using the safety offered by static code that will remain the main swift 
> paradigm.
> 
> This proposal offer new capabilities that will probably be used only for very 
> specific jobs and that is not here to replace any existing swift paradigm. 
> As dynamic capabilities will only applies to specific classes, it is easy 
> enough to avoid them if you don’t like it.
> And as the coding experience with such classes is going to be very poor (no 
> IDE assistance), I doubt people are going to use them to replace existing 
> swift patterns.

I never wanted to disallow this just discourage it. If your design warrants 
trapping behaviour then by all means you should have a way to do that.

___
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

[Jon Gilbert via swift-evolution]

See below.

> On Dec 6, 2017, at 02:45, Nick Keets via swift-evolution 
>  wrote:
> 
> Apologies, I may have misunderstood you. What I wanted to say is that I see 
> no problem allowing "dangerous" stuff that may be abused.

You see no problem with danger and abuse?

I guess we have differing philosophies...

https://developer.apple.com/swift/ states:

“Swift eliminates entire classes of unsafe code.”

Lets keep it that way.

I’m all for this proposal if it can be tweaked to where any of the dangerous 
invocations contain the word, “Unsafe”, or equivalent.

~Jon


___
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

[Jean-Daniel via swift-evolution]

> Le 8 déc. 2017 à 02:48, Letanyan Arumugam via swift-evolution 
>  a écrit :
> 
> 
> 
>> On 07 Dec 2017, at 22:26, Chris Lattner > > wrote:
>> 
>>> 
>>> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam >> > wrote:
>>> 
>> fatalError shouldn’t be used excessively. API surface areas for these 
>> types are going to be massive (infinite technically). I assume many 
>> people are going to be writing a lot of code would these types and 
>> calling many methods and properties which would all essentially have a 
>> fatalError. Would you consider it good code if the majority of all your 
>> types had methods defined with fatalError calls.
>> 
>> What is the basis for this claim? Probably the majority of standard 
>> library methods check preconditions and trap on failure. That is how I 
>> write my code as well.
>> 
> 
> I’m talking specifically about fatalError not precondition. fatalError is 
> something that goes out with production code while precondition is used 
> for debugging. I think you would agree a shipped program that has many 
> states of being unrecoverable is not a good design?
 
 You are aware that Int traps on overflow and arrays trap on out of bounds, 
 right?
 
>>> 
>>> Were each of them not decided upon separately based on certain tradeoffs? 
>>> Arrays for speed and Int overflow because having the addition operator 
>>> return an optional would be too cumbersome? If these reasons were not so 
>>> influential would they still be designed to trap?
>> 
>> Yes, each of these decisions was carefully made.  
>> 
>> My point is that pretty much all code can fail at runtime, including 
>> "something that goes out with production code”, because integers and arrays 
>> are pervasive. I do not understand your claim that Swift APIs do not 
>> generally fail at runtime.
>> 
>> -Chris
> 
> I’m just saying that we should try to avoid failure at runtime as much as we 
> can whenever we can. We shouldn’t think it’s okay to add more reasons to fail 
> at runtime because there’s already reasons to fail. We should be trying to 
> reduce these. And even if this is impossible I think its always good to try.

Failure at runtime is an intrinsic property of dynamic languages. This proposal 
does not explicitly specify what append when a lookup fails and let the bridge 
take care of this. I don’t think forcing a model would be the right way to 
introduce dynamic features in the language. With an open proposal, time will 
tell us what is the best way to bridge dynamic language and unfitted 
bridges/libraries will just be forgotten.

If having a dynamic bridge that trap on failure is an issue, just use one that 
don’t. If dynamic code feel unsafe to you, you don’t use it and keep using the 
safety offered by static code that will remain the main swift paradigm.

This proposal offer new capabilities that will probably be used only for very 
specific jobs and that is not here to replace any existing swift paradigm. 
As dynamic capabilities will only applies to specific classes, it is easy 
enough to avoid them if you don’t like it.
And as the coding experience with such classes is going to be very poor (no IDE 
assistance), I doubt people are going to use them to replace existing swift 
patterns.


___
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

[Letanyan Arumugam via swift-evolution]

> On 08 Dec 2017, at 10:04, Nick Keets  wrote:
> 
> I think this distills the fears of some of the people that are against this 
> proposal. To paraphrase, it is the fear that the dynamic type barbarians will 
> come and pillage our villages.
> 
> I on the other hand would welcome this highly hypothetical sub community. I 
> would also welcome an obfuscated swift sub community, a non-ascii names sub 
> community and any other weird sub community. I mean, why not? They are not 
> going to affect my code or the libraries I use. Why not let them exist? 
> What's with the elitism?
> 
> 
> On Fri, Dec 8, 2017 at 4:09 AM, Letanyan Arumugam via swift-evolution 
> > wrote:
> Okay I’ll concede and hope that a sub community, who are forced to use Swift 
> because of the success of this proposal and others to follow, doesn’t form 
> creating their own separate design patterns and beliefs :)

Not trying to seem elite, I just think we should all grow together and benefit 
from each other (no massive difference in style and philosophies that makes it 
difficult to cooperate).___
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 Garrigues via swift-evolution]

There are fields where there is no swift culture at all, or barely none, for 
example on the server side. I don’t want to see « swift-django » winning this 
battle. I like compile-type safety, because i know that in the long term it 
makes my code more manageable. But in some cases it’s hard to promote long term 
over short term. It’s hard to tell someone in your team « yes, you should take 
the time to define that struct for parsing your JSON api , even if you’ve got 
tight delay, rather than rely on dynamiclookup ».

Best practices don’t magically conquer a community, they do so because senior 
devs start banning the dangerous ones and because the language or compiler 
warning help them to.

> Le 8 déc. 2017 à 09:04, Nick Keets via swift-evolution 
>  a écrit :
> 
> I think this distills the fears of some of the people that are against this 
> proposal. To paraphrase, it is the fear that the dynamic type barbarians will 
> come and pillage our villages.
> 
> I on the other hand would welcome this highly hypothetical sub community. I 
> would also welcome an obfuscated swift sub community, a non-ascii names sub 
> community and any other weird sub community. I mean, why not? They are not 
> going to affect my code or the libraries I use. Why not let them exist? 
> What's with the elitism?
> 
> 
>> On Fri, Dec 8, 2017 at 4:09 AM, Letanyan Arumugam via swift-evolution 
>>  wrote:
>> Okay I’ll concede and hope that a sub community, who are forced to use Swift 
>> because of the success of this proposal and others to follow, doesn’t form 
>> creating their own separate design patterns and beliefs :)
> ___
> 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

[Letanyan Arumugam via swift-evolution]

> On 08 Dec 2017, at 00:06, Paul Cantrell  wrote:
> 
> 
>> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam  wrote:
>> 
>>> My main objection to the critical responses is that most of the objections 
>>> are fundamentally cultural, not technical, and are fear-based, not 
>>> evidence-based.
>> 
>> The goal of this proposal is to bring people from a culture where excessive 
>> use of this would be the norm for them. Why would it be so hard to imagine 
>> that people would adopt bad principles, knowing or unknowing, because this 
>> is what they’ve always done?
> 
> Languages bring in new developers who misapply their experience all the time. 
> Look at the early days of Ruby when it was actively working to pull new 
> developers away from Java, developers who were in the habit of using names 
> like AbstractItemManagerFactoryImpl. Look at beginner Swift code posted in 
> Stack Overflow questions, littered with careless force unwraps that are 
> clearly there because that’s the fixit and sort of smells like C or Java, not 
> because they actually thought about what they were doing.
> 
> Note in both cases how the center of gravity of the language did •not• move. 
> Note how poorly designed libraries that didn’t fit the language did •not• see 
> adoption. Note how the core community acted as good teachers to the newcomers.
> 
>> My fear is that a design pattern around dynamic members and calls arise that 
>> is used to bypass the perceived initial annoyance of Swifts type system from 
>> new developers that come over to Swift and are now starting to try and go 
>> native.
> 
> That contradicts the historical experience of other languages that have seen 
> “crossover” adoption from developers bringing very different mental models 
> with them.
> 
> A Swift library released today that senselessly used dynamic member lookup 
> without good engineering reason would go over just about as well as an 
> AbstractItemManagerFactoryImpl would have gone over with the Ruby community 
> in 2007.
> 
> Again, a language feature alone will not erase the good sense of the 
> language’s stewards, or poison its community.
> 
> People come to Swift to write Swift. People trying to write Python or Ruby or 
> C in Swift will feel the friction, learn from that, adjust their habits 
> taking a cue from the code they find in the surrounding ecosystem, and learn 
> to think “Swiftly.” This has been the case in every language before Swift; it 
> will not stop being the case now.
> 
> Joe hit this nail on the head:
> 
>> On Dec 7, 2017, at 10:08 AM, Joe DeCapo via swift-evolution 
>>  wrote:
>> 
>> When I began writing Python, I initially named all my variables in camel 
>> case. And when I used the Subprocess module, I was passing return codes 
>> throughout my code base like it was bash. Even though I didn't know what was 
>> idiomatic in Python at that time, I could still sense a code smell in what I 
>> was writing. I soon learned that snake case was the standard, so I updated 
>> my code. And eventually I learned how to use exceptions and I refactored my 
>> code to use them instead of return codes. I doubt that this is unusual when 
>> coming to a new language with previous experience in other languages. It 
>> seems inevitable, and a normal process for becoming familiar with the idioms 
>> of a certain language community. I don't think we need to be so fearful of 
>> the community fracturing if people from a dynamic language background come 
>> to Swift and initially use those idioms. It will always be more burdensome 
>> to do things in a non-idiomatic way, and over time people will learn how to 
>> write idiomatic Swift.
> 
> Exactly.
> 
>> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam  wrote:
>> 
>> Evidence is going to be hard to get since I don’t know any other language 
>> like Swift that has done this for the same reasons before. As far as C# goes 
>> were they trying to get people from a heavily based dynamic community or 
>> help those already in the community?
>> 
>>> If a little extra language ceremony helps assuage those fears, I guess I’d 
>>> consider it. I still think static analysis — starting and mostly ending 
>>> with boring old syntax coloring — answers most all the concerns people have 
>>> raised, and this debate is a tempest in a teapot.
>> 
>> I'm unsure of this, but as far as I’m aware Swift language proposals 
>> shouldn’t rely on editor features. But like I said I’m unsure of this and if 
>> someone could clarify this that would great.
> 
> Type inference effectively does, to at least the same degree as this 
> proposal. See my previous post reflecting on why Java chose not to have any 
> sort of type inference:
> 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041926.html
> 
> • • •
> 
> It’s wise to remember Flon’s Law:
> 
> “There is not now, nor has there ever been, nor will there 

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

[Letanyan Arumugam via swift-evolution]

> On 07 Dec 2017, at 22:26, Chris Lattner  wrote:
> 
>> 
>> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam > > wrote:
>> 
> fatalError shouldn’t be used excessively. API surface areas for these 
> types are going to be massive (infinite technically). I assume many 
> people are going to be writing a lot of code would these types and 
> calling many methods and properties which would all essentially have a 
> fatalError. Would you consider it good code if the majority of all your 
> types had methods defined with fatalError calls.
> 
> What is the basis for this claim? Probably the majority of standard 
> library methods check preconditions and trap on failure. That is how I 
> write my code as well.
> 
 
 I’m talking specifically about fatalError not precondition. fatalError is 
 something that goes out with production code while precondition is used 
 for debugging. I think you would agree a shipped program that has many 
 states of being unrecoverable is not a good design?
>>> 
>>> You are aware that Int traps on overflow and arrays trap on out of bounds, 
>>> right?
>>> 
>> 
>> Were each of them not decided upon separately based on certain tradeoffs? 
>> Arrays for speed and Int overflow because having the addition operator 
>> return an optional would be too cumbersome? If these reasons were not so 
>> influential would they still be designed to trap?
> 
> Yes, each of these decisions was carefully made.  
> 
> My point is that pretty much all code can fail at runtime, including 
> "something that goes out with production code”, because integers and arrays 
> are pervasive. I do not understand your claim that Swift APIs do not 
> generally fail at runtime.
> 
> -Chris

I’m just saying that we should try to avoid failure at runtime as much as we 
can whenever we can. We shouldn’t think it’s okay to add more reasons to fail 
at runtime because there’s already reasons to fail. We should be trying to 
reduce these. And even if this is impossible I think its always good to try.___
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 7, 2017, at 2:07 PM, Paul Cantrell via swift-evolution 
>  wrote:
> 
> 
>> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam  wrote:
>> 
>>> My main objection to the critical responses is that most of the objections 
>>> are fundamentally cultural, not technical, and are fear-based, not 
>>> evidence-based.
>> 
>> The goal of this proposal is to bring people from a culture where excessive 
>> use of this would be the norm for them. Why would it be so hard to imagine 
>> that people would adopt bad principles, knowing or unknowing, because this 
>> is what they’ve always done?
> 
> Languages bring in new developers who misapply their experience all the time. 
> Look at the early days of Ruby when it was actively working to pull new 
> developers away from Java, developers who were in the habit of using names 
> like AbstractItemManagerFactoryImpl. Look at beginner Swift code posted in 
> Stack Overflow questions, littered with careless force unwraps that are 
> clearly there because that’s the fixit and sort of smells like C or Java, not 
> because they actually thought about what they were doing.

Great post Paul.  Similarly, look at the early days of Swift, where many ObjC 
programmers used IOUs for everything.

Bad code gets written all the time, this is unavoidable.  This feature will not 
affect or measurably change that.

-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

[Paul Cantrell via swift-evolution]

> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam  wrote:
> 
>> My main objection to the critical responses is that most of the objections 
>> are fundamentally cultural, not technical, and are fear-based, not 
>> evidence-based.
> 
> The goal of this proposal is to bring people from a culture where excessive 
> use of this would be the norm for them. Why would it be so hard to imagine 
> that people would adopt bad principles, knowing or unknowing, because this is 
> what they’ve always done?

Languages bring in new developers who misapply their experience all the time. 
Look at the early days of Ruby when it was actively working to pull new 
developers away from Java, developers who were in the habit of using names like 
AbstractItemManagerFactoryImpl. Look at beginner Swift code posted in Stack 
Overflow questions, littered with careless force unwraps that are clearly there 
because that’s the fixit and sort of smells like C or Java, not because they 
actually thought about what they were doing.

Note in both cases how the center of gravity of the language did •not• move. 
Note how poorly designed libraries that didn’t fit the language did •not• see 
adoption. Note how the core community acted as good teachers to the newcomers.

> My fear is that a design pattern around dynamic members and calls arise that 
> is used to bypass the perceived initial annoyance of Swifts type system from 
> new developers that come over to Swift and are now starting to try and go 
> native.

That contradicts the historical experience of other languages that have seen 
“crossover” adoption from developers bringing very different mental models with 
them.

A Swift library released today that senselessly used dynamic member lookup 
without good engineering reason would go over just about as well as an 
AbstractItemManagerFactoryImpl would have gone over with the Ruby community in 
2007.

Again, a language feature alone will not erase the good sense of the language’s 
stewards, or poison its community.

People come to Swift to write Swift. People trying to write Python or Ruby or C 
in Swift will feel the friction, learn from that, adjust their habits taking a 
cue from the code they find in the surrounding ecosystem, and learn to think 
“Swiftly.” This has been the case in every language before Swift; it will not 
stop being the case now.

Joe hit this nail on the head:

> On Dec 7, 2017, at 10:08 AM, Joe DeCapo via swift-evolution 
>  wrote:
> 
> When I began writing Python, I initially named all my variables in camel 
> case. And when I used the Subprocess module, I was passing return codes 
> throughout my code base like it was bash. Even though I didn't know what was 
> idiomatic in Python at that time, I could still sense a code smell in what I 
> was writing. I soon learned that snake case was the standard, so I updated my 
> code. And eventually I learned how to use exceptions and I refactored my code 
> to use them instead of return codes. I doubt that this is unusual when coming 
> to a new language with previous experience in other languages. It seems 
> inevitable, and a normal process for becoming familiar with the idioms of a 
> certain language community. I don't think we need to be so fearful of the 
> community fracturing if people from a dynamic language background come to 
> Swift and initially use those idioms. It will always be more burdensome to do 
> things in a non-idiomatic way, and over time people will learn how to write 
> idiomatic Swift.

Exactly.

> On Dec 7, 2017, at 12:37 AM, Letanyan Arumugam  wrote:
> 
> Evidence is going to be hard to get since I don’t know any other language 
> like Swift that has done this for the same reasons before. As far as C# goes 
> were they trying to get people from a heavily based dynamic community or help 
> those already in the community?
> 
>> If a little extra language ceremony helps assuage those fears, I guess I’d 
>> consider it. I still think static analysis — starting and mostly ending with 
>> boring old syntax coloring — answers most all the concerns people have 
>> raised, and this debate is a tempest in a teapot.
> 
> I'm unsure of this, but as far as I’m aware Swift language proposals 
> shouldn’t rely on editor features. But like I said I’m unsure of this and if 
> someone could clarify this that would great.

Type inference effectively does, to at least the same degree as this proposal. 
See my previous post reflecting on why Java chose not to have any sort of type 
inference:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041926.html

• • •

It’s wise to remember Flon’s Law:

“There is not now, nor has there ever been, nor will there ever be, any 
programming language in which it is the least bit difficult to write bad code.”

We should design languages to make writing excellent code as pleasant and 
rewarding as possible. Or more accurately, we should 

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

[Chris Lattner via swift-evolution]

> On Dec 7, 2017, at 11:22 AM, Letanyan Arumugam  wrote:
> 
 fatalError shouldn’t be used excessively. API surface areas for these 
 types are going to be massive (infinite technically). I assume many people 
 are going to be writing a lot of code would these types and calling many 
 methods and properties which would all essentially have a fatalError. 
 Would you consider it good code if the majority of all your types had 
 methods defined with fatalError calls.
 
 What is the basis for this claim? Probably the majority of standard 
 library methods check preconditions and trap on failure. That is how I 
 write my code as well.
 
>>> 
>>> I’m talking specifically about fatalError not precondition. fatalError is 
>>> something that goes out with production code while precondition is used for 
>>> debugging. I think you would agree a shipped program that has many states 
>>> of being unrecoverable is not a good design?
>> 
>> You are aware that Int traps on overflow and arrays trap on out of bounds, 
>> right?
>> 
> 
> Were each of them not decided upon separately based on certain tradeoffs? 
> Arrays for speed and Int overflow because having the addition operator return 
> an optional would be too cumbersome? If these reasons were not so influential 
> would they still be designed to trap?

Yes, each of these decisions was carefully made.  

My point is that pretty much all code can fail at runtime, including "something 
that goes out with production code”, because integers and arrays are pervasive. 
I do not understand your claim that Swift APIs do not generally fail at runtime.

-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

[Letanyan Arumugam via swift-evolution]

Regards

Letanyan Arumugam



> On 07 Dec 2017, at 21:07, Chris Lattner  wrote:
> 
> 
>> On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>>> On 07 Dec 2017, at 17:02, Xiaodi Wu >> > wrote:
>>> 
>>> 
>>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>>> > wrote:
>>> 
 This seems marginally tolerable, but excessive.
 
 Do we mark every usage of a type that can generate precondition failures 
 or fatal errors for reasons other than “no such method?” No, we don’t.
 
>>> 
>>> fatalError shouldn’t be used excessively. API surface areas for these types 
>>> are going to be massive (infinite technically). I assume many people are 
>>> going to be writing a lot of code would these types and calling many 
>>> methods and properties which would all essentially have a fatalError. Would 
>>> you consider it good code if the majority of all your types had methods 
>>> defined with fatalError calls.
>>> 
>>> What is the basis for this claim? Probably the majority of standard library 
>>> methods check preconditions and trap on failure. That is how I write my 
>>> code as well.
>>> 
>> 
>> I’m talking specifically about fatalError not precondition. fatalError is 
>> something that goes out with production code while precondition is used for 
>> debugging. I think you would agree a shipped program that has many states of 
>> being unrecoverable is not a good design?
> 
> You are aware that Int traps on overflow and arrays trap on out of bounds, 
> right?
> 

Were each of them not decided upon separately based on certain tradeoffs? 
Arrays for speed and Int overflow because having the addition operator return 
an optional would be too cumbersome? If these reasons were not so influential 
would they still be designed to trap?

___
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 7, 2017, at 9:20 AM, BJ Homer via swift-evolution 
>  wrote:
> 
>> So while it’s theoretically possible to do this, I don’t think it’s a 
>> concern in practice. The incentives are already in place to encourage doing 
>> the “right” thing in this case, even with the possibility of dynamic member 
>> lookup.
>> 
>> -BJ
>> 
>> Hey, thanks for answering that part of the concern. i also came to this 
>> point, but wondered if the dictionary couldn't be made of type [String: 
>> DynamicValue] where DynamicValue would have some way to be  automatically 
>> casted to string, int, etc, by reusing the same mechanism that the proposal 
>> would use to convert PyVal to regular swift types. I stopped at this point.
>> 
> 
> 
> As far as I am aware, the proposal provides no mechanism for automatically 
> converting back from PyVal to regular Swift types. You would have to do 
> something explicit like myPythonValue.intValue, or String(myPythonValue).

That is correct, these proposals have nothing to do with conversions like that.

If you look at the Python prototype I sent out, the primitive types like 
Int/String/etc have failable conversion from PyVal (they return an optional).

-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

[Chris Lattner via swift-evolution]

> On Dec 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution 
>  wrote:
> 
> 
> 
>> On 07 Dec 2017, at 17:02, Xiaodi Wu > > wrote:
>> 
>> 
>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>> > wrote:
>> 
>>> This seems marginally tolerable, but excessive.
>>> 
>>> Do we mark every usage of a type that can generate precondition failures or 
>>> fatal errors for reasons other than “no such method?” No, we don’t.
>>> 
>> 
>> fatalError shouldn’t be used excessively. API surface areas for these types 
>> are going to be massive (infinite technically). I assume many people are 
>> going to be writing a lot of code would these types and calling many methods 
>> and properties which would all essentially have a fatalError. Would you 
>> consider it good code if the majority of all your types had methods defined 
>> with fatalError calls.
>> 
>> What is the basis for this claim? Probably the majority of standard library 
>> methods check preconditions and trap on failure. That is how I write my code 
>> as well.
>> 
> 
> I’m talking specifically about fatalError not precondition. fatalError is 
> something that goes out with production code while precondition is used for 
> debugging. I think you would agree a shipped program that has many states of 
> being unrecoverable is not a good design?

You are aware that Int traps on overflow and arrays trap on out of bounds, 
right?

-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

[Letanyan Arumugam via swift-evolution]

So the idea is that we shouldn’t allow dynamic lookups and calls to return 
values without some sort of error handling by default. Avoiding error handling 
should be an opt in situation. The point of having the default behaviour 
require error handling is that these protocols will always have at least one 
failure to handle.

Dynamic calls would work in much the same way as a lookup. Calls should require 
that they return an Optional or throw by default. You can then opt in to have 
the ability to return whatever you want however you want.

Remember these errors have no meaning specific to "something doesn’t exist". 
It’s whatever we want them to mean. 
However you want to model your call is up to you. If you want to just return 
Void, for whatever reason, opt in and do so just as long you are sure.

I understand that this seems like an unnecessary hinderance, but most forms of 
security/protection is.

> On 07 Dec 2017, at 19:47, Joe DeCapo  wrote:
> 
> 
>> On Dec 7, 2017, at 11:29 AM, Letanyan Arumugam > > wrote:
>> 
>> I think a better approach would still be to try and get the author of the 
>> type to make the right choice in the first place.
> 
> After rereading the post you linked to last night 
> (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042015.html
>  
> ),
>  I think it could quickly get out of hand. It might be simple enough for 
> DynamicMemberLookup, but once we get to the point of discussing 
> DynamicCallable there are many more variations.
> 
> - Calls that return Void
Opt in to unchecked behaviour and return a Void

> - Calls that return an optional

Return an optional of an optional if you wish.
Or throw a “doesntExist" and return an optional
Just return an optional and ignore the “doesn’t exist meaning” or have it imply 
either

However you want to model it do so

> - Calls that return an IUO
Opt in and return an IUO if thats the right design

> - Calls that throw
> - etc.
> 
> I know this is a discussion about DynamicMemberLookup, but DynamicCallable is 
> closely related and I imagine will end up following a similar pattern. How 
> would you propose that DynamicCallable would be annotated in this fashion? 
> There are a number of types of calls, and some are orthogonal so the 
> combinations quickly add up. People will probably have similar concerns about 
> failed call lookups as they do about member lookups.



___
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 7, 2017, at 11:29 AM, Letanyan Arumugam  wrote:
> 
> I think a better approach would still be to try and get the author of the 
> type to make the right choice in the first place.

After rereading the post you linked to last night 
(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042015.html
 
),
 I think it could quickly get out of hand. It might be simple enough for 
DynamicMemberLookup, but once we get to the point of discussing DynamicCallable 
there are many more variations.

- Calls that return Void
- Calls that return an optional
- Calls that return an IUO
- Calls that throw
- etc.

I know this is a discussion about DynamicMemberLookup, but DynamicCallable is 
closely related and I imagine will end up following a similar pattern. How 
would you propose that DynamicCallable would be annotated in this fashion? 
There are a number of types of calls, and some are orthogonal so the 
combinations quickly add up. People will probably have similar concerns about 
failed call lookups as they do about member lookups.___
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]

Reading this part of the proposal
"Now clients are able to write more natural code like:
json[0]?.name?.first?.stringValue which is close to the expressivity of
Javascript... while being fully type safe!"

gave me the feeling that communication between dynamiclookupable types and
static swift types was aimed at being quite seamless.
Now having to write ".string or .int" in the end of the dynamic expression
would indeed raise the bar a bit, but i'm still very skeptical this would
be enough to deter people from trying to import "dynamic magic"  into
swift.



On Thu, Dec 7, 2017 at 6:20 PM, BJ Homer  wrote:

>
>
> On Dec 7, 2017, at 10:16 AM, Benjamin G 
> wrote:
>
>
>
> On Thu, Dec 7, 2017 at 6:01 PM, BJ Homer  wrote:
>
>> Benjamin,
>>
>> It sounds like your concern is that people might write objects that just
>> store everything in a dictionary, instead of declaring typed properties.
>> Correct?
>>
>> On Dec 7, 2017, at 7:11 AM, Benjamin G via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> I think i answered that question many times as well (by masquerading
>> dictionaries as regular classes), but if what i'm saying is simply
>> impossible because of Swift type system even with the new proposal, i'd
>> rather people tell it to me than ask the same question over and over..
>>
>> ___
>>
>>
>> It *would* be possible, in theory, to write a class that used a
>> dictionary as a backing store for all its properties under this proposal.
>> However, the dictionary would have to be typed [String: Any?], and every
>> property access would be typed Any?. Your code would look like this:
>>
>> class MyDynamicObject: DynamicMemberLookupProtocol {
>> var storage: [String: Any?] = [:]
>>
>> subscript(dynamicMember: String) -> Any? {
>> get { return storage[dynamicMember] }
>> set(newValue) { storage[dynamicMember] = newValue }
>> }
>> }
>>
>> let x: MyDynamicObject = ...
>>
>> // setting properties is easy!
>> x.name = “Benjamin”
>> x.age = 3
>>
>> // using them, though, is hard!
>> var adults: [String] = []
>> if x.age as! Int > 18 {
>> adults.append(x.name as! String)
>> }
>>
>>
>> If you decide to create an object that stores everything in an ‘Any’,
>> Swift is going to force you to use an ‘as’ cast anytime you want to use
>> it. That’s super annoying.
>>
>> So yes, it’s possible to create a type that masquerades a dictionary as a
>> regular class. But the ergonomics of doing so are sufficiently frustrating
>> that nobody is likely to do so. Swift makes it easy to declare typed
>> variables here, and the user experience for doing so is vastly improved
>> (code completion, compile-time checking, no more ‘as’ casting, etc).
>>
>> So while it’s theoretically possible to do this, I don’t think it’s a
>> concern in practice. The incentives are already in place to encourage doing
>> the “right” thing in this case, even with the possibility of dynamic member
>> lookup.
>>
>> -BJ
>>
>
> Hey, thanks for answering that part of the concern. i also came to this
> point, but wondered if the dictionary couldn't be made of type [String:
> DynamicValue] where DynamicValue would have some way to be  automatically
> casted to string, int, etc, by reusing the same mechanism that the proposal
> would use to convert PyVal to regular swift types. I stopped at this point.
>
>
> As far as I am aware, the proposal provides no mechanism for automatically
> converting back from PyVal to regular Swift types. You would have to do
> something explicit like myPythonValue.intValue, or String(myPythonValue).
>
> -BJ
>
>
___
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

[Letanyan Arumugam via swift-evolution]

> On 07 Dec 2017, at 18:59, Joe DeCapo  wrote:
> 
> 
>> On Dec 7, 2017, at 10:41 AM, Letanyan Arumugam > > wrote:
>> 
>> I think warning and error messages would be too much. I’m not concerned 
>> about things being implemented in this way just as long as it’s appropriate. 
>> I would think all language layers like Python should have trapping lookups 
>> and calls.
> 
> To be clear, I meant a message that shows up in the console, not something 
> like a warning in the IDE. Similar to messages about autolayout constraints 
> being violated, or something of that nature.

I think a better approach would still be to try and get the author of the type 
to make the right choice in the first place.___
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

[Letanyan Arumugam via swift-evolution]

> 
>> The current design says that dynamic and static calls are on equal footing. 
>> This implies to the programmer that either way of doing things is correct. A 
>> programmer from a dynamic environment is usually going to choose the dynamic 
>> way because it’s more powerful and easier to use. I just merely want the 
>> design to have a way of showing the programmer that they should think twice 
>> about using it in an implicitly failing way. Whether that be renaming the 
>> protocol to something like UnsafeDynamicMemberLookup or something else along 
>> the lines of what Swift currently does.
> 
> I though the current design was all about easing the use of good libraries 
> that are currently only available in dynamic languages.
> 
> Do you aim at a particular paragraph in 
> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#motivation-and-context
>  ?
> 


Sorry I meant that the current design implies that dynamic and static 
calls/lookups are on equal footing (If not equal then very close). This is 
because conformance to DynamicMemberLookup is really easy.

This wasn’t about the motivation section specifically.
___
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

[BJ Homer via swift-evolution]

> On Dec 7, 2017, at 10:16 AM, Benjamin G  wrote:
> 
> 
> 
> On Thu, Dec 7, 2017 at 6:01 PM, BJ Homer  > wrote:
> Benjamin, 
> 
> It sounds like your concern is that people might write objects that just 
> store everything in a dictionary, instead of declaring typed properties. 
> Correct?
> 
>> On Dec 7, 2017, at 7:11 AM, Benjamin G via swift-evolution 
>> > wrote:
>> 
>> I think i answered that question many times as well (by masquerading 
>> dictionaries as regular classes), but if what i'm saying is simply 
>> impossible because of Swift type system even with the new proposal, i'd 
>> rather people tell it to me than ask the same question over and over..
>> 
>> ___
> 
> It would be possible, in theory, to write a class that used a dictionary as a 
> backing store for all its properties under this proposal. However, the 
> dictionary would have to be typed [String: Any?], and every property access 
> would be typed Any?. Your code would look like this:
> 
> class MyDynamicObject: DynamicMemberLookupProtocol {
> var storage: [String: Any?] = [:]
> 
> subscript(dynamicMember: String) -> Any? {
> get { return storage[dynamicMember] }
> set(newValue) { storage[dynamicMember] = newValue }
> }
> }
> 
> let x: MyDynamicObject = ...
> 
> // setting properties is easy!
> x.name  = “Benjamin”
> x.age = 3
> 
> // using them, though, is hard!
> var adults: [String] = []
> if x.age as! Int > 18 {
> adults.append(x.name  as! String)
> }
> 
> If you decide to create an object that stores everything in an ‘Any’, Swift 
> is going to force you to use an ‘as’ cast anytime you want to use it. That’s 
> super annoying.
> 
> So yes, it’s possible to create a type that masquerades a dictionary as a 
> regular class. But the ergonomics of doing so are sufficiently frustrating 
> that nobody is likely to do so. Swift makes it easy to declare typed 
> variables here, and the user experience for doing so is vastly improved (code 
> completion, compile-time checking, no more ‘as’ casting, etc).
> 
> So while it’s theoretically possible to do this, I don’t think it’s a concern 
> in practice. The incentives are already in place to encourage doing the 
> “right” thing in this case, even with the possibility of dynamic member 
> lookup.
> 
> -BJ
> 
> Hey, thanks for answering that part of the concern. i also came to this 
> point, but wondered if the dictionary couldn't be made of type [String: 
> DynamicValue] where DynamicValue would have some way to be  automatically 
> casted to string, int, etc, by reusing the same mechanism that the proposal 
> would use to convert PyVal to regular swift types. I stopped at this point.
> 


As far as I am aware, the proposal provides no mechanism for automatically 
converting back from PyVal to regular Swift types. You would have to do 
something explicit like myPythonValue.intValue, or String(myPythonValue).

-BJ

___
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 Thu, Dec 7, 2017 at 6:01 PM, BJ Homer  wrote:

> Benjamin,
>
> It sounds like your concern is that people might write objects that just
> store everything in a dictionary, instead of declaring typed properties.
> Correct?
>
> On Dec 7, 2017, at 7:11 AM, Benjamin G via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I think i answered that question many times as well (by masquerading
> dictionaries as regular classes), but if what i'm saying is simply
> impossible because of Swift type system even with the new proposal, i'd
> rather people tell it to me than ask the same question over and over..
>
> ___
>
>
> It *would* be possible, in theory, to write a class that used a
> dictionary as a backing store for all its properties under this proposal.
> However, the dictionary would have to be typed [String: Any?], and every
> property access would be typed Any?. Your code would look like this:
>
> class MyDynamicObject: DynamicMemberLookupProtocol {
> var storage: [String: Any?] = [:]
>
>
> subscript(dynamicMember: String) -> Any? {
> get { return storage[dynamicMember] }
> set(newValue) { storage[dynamicMember] = newValue }
> }
> }
>
> let x: MyDynamicObject = ...
>
> // setting properties is easy!
> x.name = “Benjamin”
> x.age = 3
>
> // using them, though, is hard!
> var adults: [String] = []
> if x.age as! Int > 18 {
> adults.append(x.name as! String)
> }
>
>
> If you decide to create an object that stores everything in an ‘Any’,
> Swift is going to force you to use an ‘as’ cast anytime you want to use
> it. That’s super annoying.
>
> So yes, it’s possible to create a type that masquerades a dictionary as a
> regular class. But the ergonomics of doing so are sufficiently frustrating
> that nobody is likely to do so. Swift makes it easy to declare typed
> variables here, and the user experience for doing so is vastly improved
> (code completion, compile-time checking, no more ‘as’ casting, etc).
>
> So while it’s theoretically possible to do this, I don’t think it’s a
> concern in practice. The incentives are already in place to encourage doing
> the “right” thing in this case, even with the possibility of dynamic member
> lookup.
>
> -BJ
>

Hey, thanks for answering that part of the concern. i also came to this
point, but wondered if the dictionary couldn't be made of type [String:
DynamicValue] where DynamicValue would have some way to be  automatically
casted to string, int, etc, by reusing the same mechanism that the proposal
would use to convert PyVal to regular swift types. I stopped at this point.
___
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

[BJ Homer via swift-evolution]

Benjamin, 

It sounds like your concern is that people might write objects that just store 
everything in a dictionary, instead of declaring typed properties. Correct?

> On Dec 7, 2017, at 7:11 AM, Benjamin G via swift-evolution 
>  wrote:
> 
> I think i answered that question many times as well (by masquerading 
> dictionaries as regular classes), but if what i'm saying is simply impossible 
> because of Swift type system even with the new proposal, i'd rather people 
> tell it to me than ask the same question over and over..
> 
> ___

It would be possible, in theory, to write a class that used a dictionary as a 
backing store for all its properties under this proposal. However, the 
dictionary would have to be typed [String: Any?], and every property access 
would be typed Any?. Your code would look like this:

class MyDynamicObject: DynamicMemberLookupProtocol {
var storage: [String: Any?] = [:]

subscript(dynamicMember: String) -> Any? {
get { return storage[dynamicMember] }
set(newValue) { storage[dynamicMember] = newValue }
}
}

let x: MyDynamicObject = ...

// setting properties is easy!
x.name = “Benjamin”
x.age = 3

// using them, though, is hard!
var adults: [String] = []
if x.age as! Int > 18 {
adults.append(x.name as! String)
}

If you decide to create an object that stores everything in an ‘Any’, Swift is 
going to force you to use an ‘as’ cast anytime you want to use it. That’s super 
annoying.

So yes, it’s possible to create a type that masquerades a dictionary as a 
regular class. But the ergonomics of doing so are sufficiently frustrating that 
nobody is likely to do so. Swift makes it easy to declare typed variables here, 
and the user experience for doing so is vastly improved (code completion, 
compile-time checking, no more ‘as’ casting, etc).

So while it’s theoretically possible to do this, I don’t think it’s a concern 
in practice. The incentives are already in place to encourage doing the “right” 
thing in this case, even with the possibility of dynamic member lookup.

-BJ___
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 7, 2017, at 10:41 AM, Letanyan Arumugam  wrote:
> 
> I think warning and error messages would be too much. I’m not concerned about 
> things being implemented in this way just as long as it’s appropriate. I 
> would think all language layers like Python should have trapping lookups and 
> calls.

To be clear, I meant a message that shows up in the console, not something like 
a warning in the IDE. Similar to messages about autolayout constraints being 
violated, or something of that nature.___
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

[Gwendal Roué via swift-evolution]

>>> I’m talking specifically about fatalError not precondition. fatalError is 
>>> something that goes out with production code while precondition is used for 
>>> debugging. I think you would agree a shipped program that has many states 
>>> of being unrecoverable is not a good design?
>> 
>> When a question is framed so that there is only one possible answer, the 
>> question is flawed.
>> 
>> The question is not whether one likes dynamism or not (the answer is pretty 
>> obvious for many people here, and we don't learn much).
> 
> One might call that a rhetorical question :) Which is probably not 
> appropriate here so I apologies for that.

It's difficult to avoid sometimes ;-)

>> It isn't if one would use the discussed features if the proposals were 
>> accepted (many here would swear they wouldn't, even if many of them will 
>> lick those dynamic features like candy, whenever appropriate, as every sane 
>> person would).
>> 
> I’m not sure anyone here ever said they wouldn’t use it. There’s just a 
> concern about how much it would be used.

Yes. And we all share this concern. Or, to put it better, I think : many Swift 
users are sold to the static safety of Swift.

Long gone are the early days when early Swift users were missing ObjC dynamism.

I may live in an echo chamber, but most Swift news I read are about strongly 
typed patterns, and the immense progress in the implementation of the Generics 
Manisfesto, which will bring even more type-safe goodness!

I thus see no threat in Chris's proposal. He even slightly obfuscates the 
identifiers so that no one jumps in by mistake.

>> Currently, it's a static vs. dynamic debate. But we should talk about a 
>> precise proposal, and a good one after that, which comes with plenty of 
>> information, and even playgrounds to look at!
> 
> I’m not taking sides on which is better (each to their own use cases). I am 
> talking about the proposals current design.

+1

> The current design says that dynamic and static calls are on equal footing. 
> This implies to the programmer that either way of doing things is correct. A 
> programmer from a dynamic environment is usually going to choose the dynamic 
> way because it’s more powerful and easier to use. I just merely want the 
> design to have a way of showing the programmer that they should think twice 
> about using it in an implicitly failing way. Whether that be renaming the 
> protocol to something like UnsafeDynamicMemberLookup or something else along 
> the lines of what Swift currently does.

I though the current design was all about easing the use of good libraries that 
are currently only available in dynamic languages.

Do you aim at a particular paragraph in 
https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#motivation-and-context
 ?

Gwendal

___
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 7, 2017, at 10:12 AM, Letanyan Arumugam via swift-evolution 
>  wrote:
> 
> My original argument about failing for no discernible reason still stands. 
> precondition is a thought out check for a failing state. member lookup 
> failures are going to be because things don’t exist for which you presumably 
> expected to exist.

Is it necessarily true that things will have to fail "for no discernible 
reason"? It's up to the implementers of the protocol for how they want to 
handle the failure case (trap/return option/throw error/etc.). But I imagine it 
could be possible to add a generic debug error message/warning message about 
lookup failing for invocations of this kind, which would give a pretty clear 
hint about what went wrong and why. Would that be enough to address your 
concerns about silent failures?___
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]

RPC predates NSProxy. The "type-safe" version of RPC was CORBA: anybody here 
use that? 

Then there was XML-RPC and then SOAP. 

The most popular version of RPC is HTTP + JSON, because http isn't blocked at 
network boundaries and because JSON was friendly to JavaScript in the browser.

So... Typesafe lost, stringly-typed won.

--
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 7, 2017, at 7:39 AM, Gwendal Roué  wrote:
> 
> 
>> Le 7 déc. 2017 à 16:33, C. Keith Ray via swift-evolution 
>>  a écrit :
>> 
>> Let's see what disasters were created by people abusing NSProxy, the ObjC 
>> moral equivalent of a dynamic member lookup type.
>> 
>> I'm not aware of anything.
> 
> 
> I'm sure you are ;-)
> 
> I'm not expert at all of early ObjC... But wasn't NSProxy the base of 
> good-old-times RPC?
> 
> OK, in 2017 we know that RPC is dangerous. For example, when `() -> Int` 
> relies on a network call, it's almost impossible to handle errors.
> 
> But still, is it because an API can be used for bad things that an API is bad?
> 
> Gwendal
> 
___
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

[Letanyan Arumugam via swift-evolution]

> On 07 Dec 2017, at 17:46, Xiaodi Wu  wrote:
> 
> On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam  > wrote:
> 
> 
>> On 07 Dec 2017, at 17:02, Xiaodi Wu > > wrote:
>> 
>> 
>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>> > wrote:
>> 
>>> This seems marginally tolerable, but excessive.
>>> 
>>> Do we mark every usage of a type that can generate precondition failures or 
>>> fatal errors for reasons other than “no such method?” No, we don’t.
>>> 
>> 
>> fatalError shouldn’t be used excessively. API surface areas for these types 
>> are going to be massive (infinite technically). I assume many people are 
>> going to be writing a lot of code would these types and calling many methods 
>> and properties which would all essentially have a fatalError. Would you 
>> consider it good code if the majority of all your types had methods defined 
>> with fatalError calls.
>> 
>> What is the basis for this claim? Probably the majority of standard library 
>> methods check preconditions and trap on failure. That is how I write my code 
>> as well.
>> 
> 
> I’m talking specifically about fatalError not precondition. fatalError is 
> something that goes out with production code while precondition is used for 
> debugging. I think you would agree a shipped program that has many states of 
> being unrecoverable is not a good design?
> 
> Precondition checks are active in release code. When a program encounters 
> conditions that have no obvious recovery, trapping immediately is the only 
> safe option; this is what Swift means by “safety” and the practice is 
> encouraged.
> 

Apologies I was looking at the -Ounchecked flag reference.
My original argument about failing for no discernible reason still stands. 
precondition is a thought out check for a failing state. member lookup failures 
are going to be because things don’t exist for which you presumably expected to 
exist.___
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 7, 2017, at 12:38 AM, Letanyan Arumugam via swift-evolution 
>  wrote:
> 
> My fear is that a design pattern around dynamic members and calls arise that 
> is used to bypass the perceived initial annoyance of Swifts type system from 
> new developers that come over to Swift and are now starting to try and go 
> native. They have no reason to think about their conforming types as 
> something that might fail because they’re using it to model behaviour that 
> they’re used to (good or bad). I don’t see why it’s so bad to remind people 
> that these conformances should be failing and only in rare cases should you 
> ever have a dynamic member lookup that is fine to ignore all failing lookups.
> 
> People coming from JavaScript could perceivably make dictionaries conform. 
> And later JSON, database, file and basically all resource API’s would follow.
> 
> Why would all of this happen rather than people behaving the way current 
> Swift community members behave?
> Because I worry that by bringing in people from other languages that a new 
> learning path is created. One where you start by learning your language 
> interoperating with Swift. And then pick up other Swift features as you go 
> along using your Python API for example. This would create a disparate Swift 
> community.

When I began writing Python, I initially named all my variables in camel case. 
And when I used the Subprocess module, I was passing return codes throughout my 
code base like it was bash. Even though I didn't know what was idiomatic in 
Python at that time, I could still sense a code smell in what I was writing. I 
soon learned that snake case was the standard, so I updated my code. And 
eventually I learned how to use exceptions and I refactored my code to use them 
instead of return codes. I doubt that this is unusual when coming to a new 
language with previous experience in other languages. It seems inevitable, and 
a normal process for becoming familiar with the idioms of a certain language 
community. I don't think we need to be so fearful of the community fracturing 
if people from a dynamic language background come to Swift and initially use 
those idioms. It will always be more burdensome to do things in a non-idiomatic 
way, and over time people will learn how to write idiomatic Swift.

Also, since this is an expert-level feature, I highly doubt that newcomers to 
Swift will be writing their own types that adopt the DynamicMemberLookup or 
DynamicCallable protocols. They'll simply be using existing bridges to the 
dynamic language they want to interact with. And if expert Swift users find a 
legitimate use case for this beyond dynamic language interop, I don't think 
that's necessarily a bad thing if it helps them solve their problem.

___
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

[Letanyan Arumugam via swift-evolution]

Regards

Letanyan Arumugam



> On 07 Dec 2017, at 17:34, Gwendal Roué  wrote:
> 
>> 
>> Le 7 déc. 2017 à 16:15, Letanyan Arumugam via swift-evolution 
>> > a écrit :
>> 
>> 
>> 
>>> On 07 Dec 2017, at 17:02, Xiaodi Wu >> > wrote:
>>> 
>>> 
>>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>>> > wrote:
>>> 
 This seems marginally tolerable, but excessive.
 
 Do we mark every usage of a type that can generate precondition failures 
 or fatal errors for reasons other than “no such method?” No, we don’t.
 
>>> 
>>> fatalError shouldn’t be used excessively. API surface areas for these types 
>>> are going to be massive (infinite technically). I assume many people are 
>>> going to be writing a lot of code would these types and calling many 
>>> methods and properties which would all essentially have a fatalError. Would 
>>> you consider it good code if the majority of all your types had methods 
>>> defined with fatalError calls.
>>> 
>>> What is the basis for this claim? Probably the majority of standard library 
>>> methods check preconditions and trap on failure. That is how I write my 
>>> code as well.
>>> 
>> 
>> I’m talking specifically about fatalError not precondition. fatalError is 
>> something that goes out with production code while precondition is used for 
>> debugging. I think you would agree a shipped program that has many states of 
>> being unrecoverable is not a good design?
> 
> When a question is framed so that there is only one possible answer, the 
> question is flawed.
> 
> The question is not whether one likes dynamism or not (the answer is pretty 
> obvious for many people here, and we don't learn much).

One might call that a rhetorical question :) Which is probably not appropriate 
here so I apologies for that.

> 
> It isn't if one would use the discussed features if the proposals were 
> accepted (many here would swear they wouldn't, even if many of them will lick 
> those dynamic features like candy, whenever appropriate, as every sane person 
> would).
> 
I’m not sure anyone here ever said they wouldn’t use it. There’s just a concern 
about how much it would be used.


> Currently, it's a static vs. dynamic debate. But we should talk about a 
> precise proposal, and a good one after that, which comes with plenty of 
> information, and even playgrounds to look at!
> 

I’m not taking sides on which is better (each to their own use cases). I am 
talking about the proposals current design. The current design says that 
dynamic and static calls are on equal footing. This implies to the programmer 
that either way of doing things is correct. A programmer from a dynamic 
environment is usually going to choose the dynamic way because it’s more 
powerful and easier to use. I just merely want the design to have a way of 
showing the programmer that they should think twice about using it in an 
implicitly failing way. Whether that be renaming the protocol to something like 
UnsafeDynamicMemberLookup or something else along the lines of what Swift 
currently does.



___
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

[Goffredo Marocchi via swift-evolution]

Well, mocking was effective and super easy to do proper unit testing with... 
that must count as a disaster or something ;).

Sent from my iPhone

> On 7 Dec 2017, at 15:32, C. Keith Ray via swift-evolution 
>  wrote:
> 
> Let's see what disasters were created by people abusing NSProxy, the ObjC 
> moral equivalent of a dynamic member lookup type.
> 
> I'm not aware of anything.
> 
> --
> 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 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution 
>>  wrote:
>> 
>> 
>> 
>>> On 07 Dec 2017, at 17:02, Xiaodi Wu  wrote:
>>> 
>>> 
 On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
  wrote:
 
> This seems marginally tolerable, but excessive.
> 
> Do we mark every usage of a type that can generate precondition failures 
> or fatal errors for reasons other than “no such method?” No, we don’t.
> 
 
 fatalError shouldn’t be used excessively. API surface areas for these 
 types are going to be massive (infinite technically). I assume many people 
 are going to be writing a lot of code would these types and calling many 
 methods and properties which would all essentially have a fatalError. 
 Would you consider it good code if the majority of all your types had 
 methods defined with fatalError calls.
>>> 
>>> What is the basis for this claim? Probably the majority of standard library 
>>> methods check preconditions and trap on failure. That is how I write my 
>>> code as well.
 
>> 
>> I’m talking specifically about fatalError not precondition. fatalError is 
>> something that goes out with production code while precondition is used for 
>> debugging. I think you would agree a shipped program that has many states of 
>> being unrecoverable is not a good design?
>> ___
>> 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

[Xiaodi Wu via swift-evolution]

On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam  wrote:

>
>
> On 07 Dec 2017, at 17:02, Xiaodi Wu  wrote:
>
>
> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>>
>> This seems marginally tolerable, but excessive.
>>
>> Do we mark every usage of a type that can generate precondition failures
>> or fatal errors for reasons other than “no such method?” No, we don’t.
>>
>> fatalError shouldn’t be used excessively. API surface areas for these
>> types are going to be massive (infinite technically). I assume many people
>> are going to be writing a lot of code would these types and calling many
>> methods and properties which would all essentially have a fatalError. Would
>> you consider it good code if the majority of all your types had methods
>> defined with fatalError calls.
>>
>
> What is the basis for this claim? Probably the majority of standard
> library methods check preconditions and trap on failure. That is how I
> write my code as well.
>
>>
>>
> I’m talking specifically about fatalError not precondition. fatalError is
> something that goes out with production code while precondition is used for
> debugging. I think you would agree a shipped program that has many states
> of being unrecoverable is not a good design?
>

Precondition checks are active in release code. When a program encounters
conditions that have no obvious recovery, trapping immediately is the only
safe option; this is what Swift means by “safety” and the practice is
encouraged.

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

[Gwendal Roué via swift-evolution]

> Le 7 déc. 2017 à 16:33, C. Keith Ray via swift-evolution 
>  a écrit :
> 
> Let's see what disasters were created by people abusing NSProxy, the ObjC 
> moral equivalent of a dynamic member lookup type.
> 
> I'm not aware of anything.


I'm sure you are ;-)

I'm not expert at all of early ObjC... But wasn't NSProxy the base of 
good-old-times RPC?

OK, in 2017 we know that RPC is dangerous. For example, when `() -> Int` relies 
on a network call, it's almost impossible to handle errors.

But still, is it because an API can be used for bad things that an API is bad?

Gwendal

___
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

[Gwendal Roué via swift-evolution]

> Le 7 déc. 2017 à 16:15, Letanyan Arumugam via swift-evolution 
>  a écrit :
> 
> 
> 
>> On 07 Dec 2017, at 17:02, Xiaodi Wu > > wrote:
>> 
>> 
>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>> > wrote:
>> 
>>> This seems marginally tolerable, but excessive.
>>> 
>>> Do we mark every usage of a type that can generate precondition failures or 
>>> fatal errors for reasons other than “no such method?” No, we don’t.
>>> 
>> 
>> fatalError shouldn’t be used excessively. API surface areas for these types 
>> are going to be massive (infinite technically). I assume many people are 
>> going to be writing a lot of code would these types and calling many methods 
>> and properties which would all essentially have a fatalError. Would you 
>> consider it good code if the majority of all your types had methods defined 
>> with fatalError calls.
>> 
>> What is the basis for this claim? Probably the majority of standard library 
>> methods check preconditions and trap on failure. That is how I write my code 
>> as well.
>> 
> 
> I’m talking specifically about fatalError not precondition. fatalError is 
> something that goes out with production code while precondition is used for 
> debugging. I think you would agree a shipped program that has many states of 
> being unrecoverable is not a good design?

When a question is framed so that there is only one possible answer, the 
question is flawed.

The question is not whether one likes dynamism or not (the answer is pretty 
obvious for many people here, and we don't learn much).

It isn't if one would use the discussed features if the proposals were accepted 
(many here would swear they wouldn't, even if many of them will lick those 
dynamic features like candy, whenever appropriate, as every sane person would).

Currently, it's a static vs. dynamic debate. But we should talk about a precise 
proposal, and a good one after that, which comes with plenty of information, 
and even playgrounds to look at!

Gwendal

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

Let's see what disasters were created by people abusing NSProxy, the ObjC moral 
equivalent of a dynamic member lookup type.

I'm not aware of anything.

--
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 7, 2017, at 7:15 AM, Letanyan Arumugam via swift-evolution 
>  wrote:
> 
> 
> 
>> On 07 Dec 2017, at 17:02, Xiaodi Wu  wrote:
>> 
>> 
>>> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
>>>  wrote:
>>> 
 This seems marginally tolerable, but excessive.
 
 Do we mark every usage of a type that can generate precondition failures 
 or fatal errors for reasons other than “no such method?” No, we don’t.
 
>>> 
>>> fatalError shouldn’t be used excessively. API surface areas for these types 
>>> are going to be massive (infinite technically). I assume many people are 
>>> going to be writing a lot of code would these types and calling many 
>>> methods and properties which would all essentially have a fatalError. Would 
>>> you consider it good code if the majority of all your types had methods 
>>> defined with fatalError calls.
>> 
>> What is the basis for this claim? Probably the majority of standard library 
>> methods check preconditions and trap on failure. That is how I write my code 
>> as well.
>>> 
> 
> I’m talking specifically about fatalError not precondition. fatalError is 
> something that goes out with production code while precondition is used for 
> debugging. I think you would agree a shipped program that has many states of 
> being unrecoverable is not a good design?
> ___
> 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

[Letanyan Arumugam via swift-evolution]

> On 07 Dec 2017, at 17:02, Xiaodi Wu  wrote:
> 
> 
> On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution 
> > wrote:
> 
>> This seems marginally tolerable, but excessive.
>> 
>> Do we mark every usage of a type that can generate precondition failures or 
>> fatal errors for reasons other than “no such method?” No, we don’t.
>> 
> 
> fatalError shouldn’t be used excessively. API surface areas for these types 
> are going to be massive (infinite technically). I assume many people are 
> going to be writing a lot of code would these types and calling many methods 
> and properties which would all essentially have a fatalError. Would you 
> consider it good code if the majority of all your types had methods defined 
> with fatalError calls.
> 
> What is the basis for this claim? Probably the majority of standard library 
> methods check preconditions and trap on failure. That is how I write my code 
> as well.
> 

I’m talking specifically about fatalError not precondition. fatalError is 
something that goes out with production code while precondition is used for 
debugging. I think you would agree a shipped program that has many states of 
being unrecoverable is not a good design?___
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

[Xiaodi Wu via swift-evolution]

On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution <
swift-evolution@swift.org> wrote:

>
> This seems marginally tolerable, but excessive.
>
> Do we mark every usage of a type that can generate precondition failures
> or fatal errors for reasons other than “no such method?” No, we don’t.
>
> fatalError shouldn’t be used excessively. API surface areas for these
> types are going to be massive (infinite technically). I assume many people
> are going to be writing a lot of code would these types and calling many
> methods and properties which would all essentially have a fatalError. Would
> you consider it good code if the majority of all your types had methods
> defined with fatalError calls.
>

What is the basis for this claim? Probably the majority of standard library
methods check preconditions and trap on failure. That is how I write my
code as well.

What’s so wrong with adding another layer of protection on top to bypass if
> you want to do this.
>
> Do we use a syntactically privileged marker instead of just using words
> like “unsafe” for types that expose direct access to raw memory? No, we
> don’t.
>
> Okay we use Unsafe. Then should we have something similar for this. A
> UncheckedDynamicMemberLookup [1] and a DynamicMemberLookup [2]? my one
> objection to this would be that I would like to convert a
> UncheckedDynamicMemberLookup to a DynamicMemberLookup.
>
> [1] would work like the current proposal for DynamicMemberLookup
> [2] would only allow returning an optional
>
>
> My main objection to the critical responses is that most of the objections
> are fundamentally cultural, not technical, and are fear-based, not
> evidence-based.
>
>
> The goal of this proposal is to bring people from a culture where
> excessive use of this would be the norm for them. Why would it be so hard
> to imagine that people would adopt bad principles, knowing or unknowing,
> because this is what they’ve always done?
>
> Evidence is going to be hard to get since I don’t know any other language
> like Swift that has done this for the same reasons before. As far as C#
> goes were they trying to get people from a heavily based dynamic community
> or help those already in the community?
>
>
> If a little extra language ceremony helps assuage those fears, I guess I’d
> consider it. I still think static analysis — starting and mostly ending
> with boring old syntax coloring — answers most all the concerns people have
> raised, and this debate is a tempest in a teapot.
>
>
> I'm unsure of this, but as far as I’m aware Swift language proposals
> shouldn’t rely on editor features. But like I said I’m unsure of this and
> if someone could clarify this that would great.
>
>
> ___
> 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]

On Wed, Dec 6, 2017 at 6:14 PM, Chris Lattner  wrote:

> On Dec 6, 2017, at 5:41 AM, Vincent Esche via swift-evolution <
> swift-evolution@swift.org> wrote:
> > Alas while Swift's generics provide a nice basic foundation, they still
> have big gaps in what can be expressed through them.
> > And i'm not talking about HKT or any such more advanced use of types).
> I'm talking about the basic stuff. Generic abstractions over type
> conversion. Generic abstractions over arithmetic operators. This kind of
> stuff. Stuff, that ironically would be necessary for a generic yet
> idiomatic implementation of Linear Algebra algorithms in Swift.
>
> This is all orthogonal to the proposal.  I’m certainly not opposed to the
> generics system getting better :-), […]
>

Exactly. That’s my whole point. How do we make sure these are understood to
be orthogonal? We’re talking about the average Joe here.
For someone used to stringly-typed dictionaries (Python e.g.) and
stringly-typed reflection (many message-passing/dynamic languages) it will
not be clear that 9/10 times dynamic stringly-typed member lookup is not
the right tool of choice for modeling type relations in a statically typed
language, which is exactly how these things are done in many scripting
languages.

> And I think that we have more urgent topics at hand that need to get
> fixed.
> > Swift's generics are very limited. We hardly have any tooling.
> > Diagnostics are just shy of migrating from "utter garbage" to "getting
> usable", by modern standards.
> > Integration with Xcode still to this day is an utter clusterfuck. With
> errors pointing to the void, regularly.
> > I'd prefer the team to focus on these, solidifying the foundation and
> once that's done
> > and the result have been proven to be sound by time I'd love to see
> Swift get some more dynamism.
>
> I’m not disagreeing with your point about other things needing to be
> improved, but the only question is whether this proposal fits with the
> right long term direction for Swift.  It is not a prioritization question.
>

I’m not so much thinking of it as a prioritization issue (as you already
did the implementation and made clear from the beginning that you would do
the heavy lifting, not the core team), but more of a timing issue. It
absolutely is a timing issue from my point of view, for the very reasons
that I gave previously.

A frequent argument against any of the reasonable doubts expressed in this
thread is the notion that the community “would figure something out” and
“prevent any anti-patterns and misuses from gaining a foothold”.

I have doubts about this. There is plenty of evidence for the contrary:

- We don't have a strong unit testing culture in the swift community.
Hardly any Swift project on Github has proper unit test coverage. Most have
none at all.
  And I can’t blame them/us, as XCTest is more of a burden to use than a
help. XCTest on Linux is even worse if not border-line offensive to work
with.
- We don't have a strong culture of “avoid IUOs at all costs” either. I see
them all over the place when going through random Github projects.
  They are everywhere. I would give you numbers, but “!” is kinda hard to
search for (i.e. impossible) using Github’s source code search feature.
- There is still plenty of use of AnyObject and its cousins where for a
long time we have had better solutions.
- There is still incredible amounts of non-typesafe APIs (and I’m talking
about fresh 3rd-party stuff here, not legacy frameworks).
- …

> At this point in time it's like opening Pandora's box.
>
> I, still, have yet to see any evidence of harm that this proposal can
> cause.
>

The harm from my perspective is not so much of technical nature than more
of a cultural one.
And plenty of “evidence” has been provided in this thread for why this
proposal is a risk for the language.

If not then Letanyan put it perfectly:

On Thu, Dec 7, 2017 at 7:37 AM, Letanyan Arumugam via swift-evolution <
swift-evolution@swift.org> wrote:

> My main objection to the critical responses is that most of the objections
> are fundamentally cultural, not technical, and are fear-based, not
> evidence-based.
>
>
> The goal of this proposal is to *bring people from a culture where
> excessive use of this would be the norm for them*. *Why would it be so
> hard to imagine that people would adopt bad principles, knowing or
> unknowing, because this is what they’ve always done?*
>

> Evidence is going to be hard to get since I don’t know any other language
> like Swift that has done this for the same reasons before. As far as C#
> goes were they trying to get people from a heavily based dynamic community
> or help those already in the community?
>

[…]


My fear is that a design pattern around dynamic members and calls arise
> that is *used to bypass the perceived initial annoyance of Swifts type
> system from new developers that come over to Swift* and are now starting
> to try and go native. They *have 

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

[Gwendal Roué via swift-evolution]

> Le 7 déc. 2017 à 13:59, Benjamin G  a écrit :
> 
> 
> 
> On Thu, Dec 7, 2017 at 1:45 PM, Gwendal Roué  > wrote:
> 
>> Le 7 déc. 2017 à 11:00, Benjamin G via swift-evolution 
>> > a écrit :
>> 
>> Until, and if, the “resistance” presents some conceptual explanation of how 
>> this could cause harm (I’m not asking for anything concrete, just a logical 
>> series of events that causes a plausible problem in practice), my belief is 
>> that the Swift community will see this as unwarranted fear.
>> 
>> On the server side : 
>> automatically generate an administration api for your model based on 
>> introspection. Since swift doesn't provide anything convenient, and people 
>> may simply try to "port" approach from python framework (like django), 
>> they'll resort on recreating some kind of BaseDynamicObject that you'll have 
>> to extend for all your base classe, using some "properties()" and 
>> "methods()" functions to define your properties and methods for your model.
>> 
>> Or :
>> Automatically generate a database schema based on your model. Same idea.
> 
> The explicit harm that Chris is looking for is yet to be shown. 
> 
> The harm isn't in generating the database schema, or the administration api. 
> it's in abandonning all kind of compile-time safety in your model layer (and 
> such by extension in almost every part of your stack) in order to accomplish 
> this. Dynamic language obviously don't have this concern, but thankfully 
> Swift isn't a dynamic language.

Yes, yes, but this has been said dozens of time already in this thread. Chris's 
question is *how*, not *what*. It's much harder to answer, I agree.

>>  You should not assume that everybody feels an horror thrill by reading such 
>> applications of dynamism. As a matter of fact, users of dynamic languages 
>> *live* and *enjoy* this. Python and Ruby users, obviously (Rails + Django), 
>> but also ours close cousins, the Objective-C developers, who rely on 
>> Key-Value coding or validation methods. Those use cases are, I'm sorry to 
>> say it, *compelling* use cases for dynamism.
> 
> 
> Not sure what field you're working in, but at least on the server the general 
> trend toward more compile-time safety has been pretty obvious for some time 
> now.

I'm not sure you really care about my answer.

Gwendal

___
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 Thu, Dec 7, 2017 at 1:45 PM, Gwendal Roué  wrote:

>
> Le 7 déc. 2017 à 11:00, Benjamin G via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> Until, and if, the “resistance” presents some conceptual explanation of
>> how this could cause harm (I’m not asking for anything concrete, just a
>> logical series of events that causes a plausible problem in practice), my
>> belief is that the Swift community will see this as unwarranted fear.
>>
>
> On the server side :
> automatically generate an administration api for your model based on
> introspection. Since swift doesn't provide anything convenient, and people
> may simply try to "port" approach from python framework (like django),
> they'll resort on recreating some kind of BaseDynamicObject that you'll
> have to extend for all your base classe, using some "properties()" and
> "methods()" functions to define your properties and methods for your model.
>
> Or :
> Automatically generate a database schema based on your model. Same idea.
>
>
> The explicit harm that Chris is looking for is yet to be shown.
>

The harm isn't in generating the database schema, or the administration
api. it's in abandonning all kind of compile-time safety in your model
layer (and such by extension in almost every part of your stack) in order
to accomplish this. Dynamic language obviously don't have this concern, but
thankfully Swift isn't a dynamic language.


>
> You should not assume that everybody feels an horror thrill by reading
> such applications of dynamism. As a matter of fact, users of dynamic
> languages *live* and *enjoy* this. Python and Ruby users, obviously (Rails
> + Django), but also ours close cousins, the Objective-C developers, who
> rely on Key-Value coding or validation methods. Those use cases are, I'm
> sorry to say it, *compelling* use cases for dynamism.
>

Not sure what field you're working in, but at least on the server the
general trend toward more compile-time safety has been pretty obvious for
some time now.


>
> Ironically, "Explicit is better than implicit" is a... Python motto ;-)
>

It's also a community that used to rely on writing types annotation and
signatures in comments above functions as a best practice, before
annotations became a thing. Not sure we should take it as an example.


>
> Gwendal
>
>
___
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 Thu, Dec 7, 2017 at 6:41 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> On Dec 6, 2017, at 8:11 PM, Joe DeCapo via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Has all of this ruined the language thus far? No. Because the Swift core
> team doesn’t design, and the Swift community doesn’t adopt, ill-designed
> APIs that turn these facts into problems.
>
>
> Yeah, I think I'd prefer this to stay as a normal protocol conformance.
> But if the proportion of resistance is high enough,…
>
>
> Until, and if, the “resistance” presents some conceptual explanation of
> how this could cause harm (I’m not asking for anything concrete, just a
> logical series of events that causes a plausible problem in practice), my
> belief is that the Swift community will see this as unwarranted fear.
>

On the server side :
automatically generate an administration api for your model based on
introspection. Since swift doesn't provide anything convenient, and people
may simply try to "port" approach from python framework (like django),
they'll resort on recreating some kind of BaseDynamicObject that you'll
have to extend for all your base classe, using some "properties()" and
"methods()" functions to define your properties and methods for your model.

Or :
Automatically generate a database schema based on your model. Same idea.





>
> This is particularly true given that the proposal is completely consistent
> with previous design decisions in Swift, decisions which have served us
> well.
>
> -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

[Letanyan Arumugam via swift-evolution]

> Until, and if, the “resistance” presents some conceptual explanation of how 
> this could cause harm (I’m not asking for anything concrete, just a logical 
> series of events that causes a plausible problem in practice), my belief is 
> that the Swift community will see this as unwarranted fear.
> 

My fear is that a design pattern around dynamic members and calls arise that is 
used to bypass the perceived initial annoyance of Swifts type system from new 
developers that come over to Swift and are now starting to try and go native. 
They have no reason to think about their conforming types as something that 
might fail because they’re using it to model behaviour that they’re used to 
(good or bad). I don’t see why it’s so bad to remind people that these 
conformances should be failing and only in rare cases should you ever have a 
dynamic member lookup that is fine to ignore all failing lookups.

People coming from JavaScript could perceivably make dictionaries conform. And 
later JSON, database, file and basically all resource API’s would follow.

Why would all of this happen rather than people behaving the way current Swift 
community members behave?
Because I worry that by bringing in people from other languages that a new 
learning path is created. One where you start by learning your language 
interoperating with Swift. And then pick up other Swift features as you go 
along using your Python API for example. This would create a disparate Swift 
community.
___
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

[Letanyan Arumugam via swift-evolution]

> This seems marginally tolerable, but excessive.
> 
> Do we mark every usage of a type that can generate precondition failures or 
> fatal errors for reasons other than “no such method?” No, we don’t.
> 
fatalError shouldn’t be used excessively. API surface areas for these types are 
going to be massive (infinite technically). I assume many people are going to 
be writing a lot of code would these types and calling many methods and 
properties which would all essentially have a fatalError. Would you consider it 
good code if the majority of all your types had methods defined with fatalError 
calls. What’s so wrong with adding another layer of protection on top to bypass 
if you want to do this.

> Do we use a syntactically privileged marker instead of just using words like 
> “unsafe” for types that expose direct access to raw memory? No, we don’t.
Okay we use Unsafe. Then should we have something similar for this. A 
UncheckedDynamicMemberLookup [1] and a DynamicMemberLookup [2]? my one 
objection to this would be that I would like to convert a 
UncheckedDynamicMemberLookup to a DynamicMemberLookup.

[1] would work like the current proposal for DynamicMemberLookup
[2] would only allow returning an optional

> 
> My main objection to the critical responses is that most of the objections 
> are fundamentally cultural, not technical, and are fear-based, not 
> evidence-based.

The goal of this proposal is to bring people from a culture where excessive use 
of this would be the norm for them. Why would it be so hard to imagine that 
people would adopt bad principles, knowing or unknowing, because this is what 
they’ve always done?

Evidence is going to be hard to get since I don’t know any other language like 
Swift that has done this for the same reasons before. As far as C# goes were 
they trying to get people from a heavily based dynamic community or help those 
already in the community?

> 
> If a little extra language ceremony helps assuage those fears, I guess I’d 
> consider it. I still think static analysis — starting and mostly ending with 
> boring old syntax coloring — answers most all the concerns people have 
> raised, and this debate is a tempest in a teapot.


I'm unsure of this, but as far as I’m aware Swift language proposals shouldn’t 
rely on editor features. But like I said I’m unsure of this and if someone 
could clarify this that would great.


___
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 6, 2017, at 8:11 PM, Joe DeCapo via swift-evolution 
 wrote:
>> Has all of this ruined the language thus far? No. Because the Swift core 
>> team doesn’t design, and the Swift community doesn’t adopt, ill-designed 
>> APIs that turn these facts into problems.
> 
> 
> Yeah, I think I'd prefer this to stay as a normal protocol conformance. But 
> if the proportion of resistance is high enough,…

Until, and if, the “resistance” presents some conceptual explanation of how 
this could cause harm (I’m not asking for anything concrete, just a logical 
series of events that causes a plausible problem in practice), my belief is 
that the Swift community will see this as unwarranted fear.

This is particularly true given that the proposal is completely consistent with 
previous design decisions in Swift, decisions which have served us well.

-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 6, 2017, at 9:45 PM, Paul Cantrell  wrote:
> 
> This seems marginally tolerable, but excessive.
> 
> Do we mark every usage of a type that can generate precondition failures or 
> fatal errors for reasons other than “no such method?” No, we don’t.
> 
> Do we use a syntactically privileged marker instead of just using words like 
> “unsafe” for types that expose direct access to raw memory? No, we don’t.
> 
> Has all of this ruined the language thus far? No. Because the Swift core team 
> doesn’t design, and the Swift community doesn’t adopt, ill-designed APIs that 
> turn these facts into problems.


Yeah, I think I'd prefer this to stay as a normal protocol conformance. But if 
the proportion of resistance is high enough, I think the adoption of some 
annotation above and beyond the norm would be ok (again, at the declaration 
site, not the call site). Especially since this is a somewhat privileged 
protocol if any of the restrictions suggested in the proposal go forward, since 
they don't really apply to normal protocols.

> My main objection to the critical responses is that most of the objections 
> are fundamentally cultural, not technical, and are fear-based, not 
> evidence-based.
> 
> If a little extra language ceremony helps assuage those fears, I guess I’d 
> consider it. I still think static analysis — starting and mostly ending with 
> boring old syntax coloring — answers most all the concerns people have 
> raised, and this debate is a tempest in a teapot.

I agree wholeheartedly. I was just trying to bring some specifics to the 
examples given so far.___
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 6, 2017, at 5:46 PM, Letanyan Arumugam  wrote:
> 
> But IUO’s are marked with an “!” to differentiate it from a normal type, 
> where as DynamicMemberLookup is just a normal protocol conformance. I would 
> be curious as to what you think of this idea [1]? Would this still be too 
> much of a constraint just to make sure that when people use this they’re 
> explicitly aware of what they’re doing?

I think that sort of approach seems like an acceptable middle ground. There's 
probably some bike-shedding to be done about the terminology and such. I just 
think it's overboard to require explicit annotations at the call site 
(especially for every single call site invocation). I would totally be fine 
with some sort of extra annotation at the declaration site beyond a normal 
protocol conformance. I do think this jibes well with C#'s `dynamic` approach 
from what I've gathered so far, and which other people seem to think is a 
worthy standard we should look toward for inspiration.

My main objection to many of the critical responses to the proposal is that the 
examples all seem to ignore where the variables that are being invoked come 
from. I think we all tend to have a pretty good idea of what types we're 
dealing with, and what their behaviors are. And when we run into issues, we 
inspect those types. If this makes it more apparent on inspection that it has 
some special behavior, then I'm all for that. It would be similar to inspecting 
a type that crashed which turned out to be an IUO.

___
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

[Letanyan Arumugam via swift-evolution]

> On 06 Dec 2017, at 20:54, Joe DeCapo via swift-evolution 
>  wrote:
> 
> 
>> On Dec 6, 2017, at 12:39 PM, Thorsten Seitz via swift-evolution 
>> > wrote:
>> 
>> IUO is Swift’s equivalent to a null pointer and those are a _hole_ in the 
>> type system (this applies to all type systems having an equivalent to the 
>> null pointer). That is why such types are marked with "!“ in Swift.
>> This does not mean that Swift has no type system but that it’s type system 
>> has carefully marked holes.
> 
> But the types are only marked with "!" at the declaration site, just as types 
> conforming to DynamicMemberLookup and DynamicCallable would be marked at the 
> declaration site. There's no more indication at the call site that something 
> is an IUO than there would be for something conforming to these protocols. 
> They both require inspecting the type itself.

But IUO’s are marked with an “!” to differentiate it from a normal type, where 
as DynamicMemberLookup is just a normal protocol conformance. I would be 
curious as to what you think of this idea [1]? Would this still be too much of 
a constraint just to make sure that when people use this they’re explicitly 
aware of what they’re doing?


[1]: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042015.html
 

___
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 6, 2017, at 12:39 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> IUO is Swift’s equivalent to a null pointer and those are a _hole_ in the 
> type system (this applies to all type systems having an equivalent to the 
> null pointer). That is why such types are marked with "!“ in Swift.
> This does not mean that Swift has no type system but that it’s type system 
> has carefully marked holes.

But the types are only marked with "!" at the declaration site, just as types 
conforming to DynamicMemberLookup and DynamicCallable would be marked at the 
declaration site. There's no more indication at the call site that something is 
an IUO than there would be for something conforming to these protocols. They 
both require inspecting the type itself.___
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

[Thorsten Seitz via swift-evolution]

> Am 06.12.2017 um 02:38 schrieb Chris Lattner :
> 
> On Dec 5, 2017, at 11:13 AM, Thorsten Seitz  wrote:
>>> 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.
>> 
>> I just wanted to add that the single purpose of a static type system is to 
>> ensure that the methods being called on a receiver are present at runtime 
>> and take arguments of the types known at compile time.
> 
> Then, by your definition, Swift must not have a static type system.   Two 
> examples:
> 
>x.b   // when x is an IUO
>a + b// as implemented today in the Python bridge prototype I sent out.
> 

IUO is Swift’s equivalent to a null pointer and those are a _hole_ in the type 
system (this applies to all type systems having an equivalent to the null 
pointer). That is why such types are marked with "!“ in Swift.
This does not mean that Swift has no type system but that it’s type system has 
carefully marked holes.

-Thorsten




___
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 6, 2017, at 5:41 AM, Vincent Esche via swift-evolution 
 wrote:
> Alas while Swift's generics provide a nice basic foundation, they still have 
> big gaps in what can be expressed through them.
> And i'm not talking about HKT or any such more advanced use of types). I'm 
> talking about the basic stuff. Generic abstractions over type conversion. 
> Generic abstractions over arithmetic operators. This kind of stuff. Stuff, 
> that ironically would be necessary for a generic yet idiomatic implementation 
> of Linear Algebra algorithms in Swift.

This is all orthogonal to the proposal.  I’m certainly not opposed to the 
generics system getting better :-), but there isn’t some opportunity cost where 
you choose one or the other.  The Swift team at Apple which are doing the 
majority of the generics work isn’t going to implement these proposals.

> And I think that we have more urgent topics at hand that need to get fixed.
> Swift's generics are very limited. We hardly have any tooling.
> Diagnostics are just shy of migrating from "utter garbage" to "getting 
> usable", by modern standards.
> Integration with Xcode still to this day is an utter clusterfuck. With errors 
> pointing to the void, regularly.
> I'd prefer the team to focus on these, solidifying the foundation and once 
> that's done
> and the result have been proven to be sound by time I'd love to see Swift get 
> some more dynamism.

I’m not disagreeing with your point about other things needing to be improved, 
but the only question is whether this proposal fits with the right long term 
direction for Swift.  It is not a prioritization question.

> At this point in time it's like opening Pandora's box.

I, still, have yet to see any evidence of harm that this proposal can cause.

> - How do you plan to teach the proper use of this feature? How would the 
> documentation introduce it
> and how would it ensure that people fully understand its purpose and what it 
> decidedly is _not_ for?
> - How would the diagnostics (in particular in code mixing static and dynamic 
> Swift) look like?
> - How would the debugging of dynamic APIs look like?

This is an expert-only feature like the ExpressibleBy protocols.  This is not 
something that will be introduced or taught in chapter one of the Swift book, 
or in the Swift Tour.

-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

[Chris Lattner via swift-evolution]

On Dec 5, 2017, at 11:51 PM, Jonathan Hull  wrote:
> Ok, I have changed my mind about the need for a marker, and will accept the 
> proposal as-is.  I realized that these dynamic member lookup types can just 
> be made inner types, and so I can easily create the .dynamic behavior in my 
> own code if I want under the current proposal.  I also realized that 
> requiring a marker would screw up the proxy use-case of this.
> 
> I do still have a couple of questions I am confused on:

Hi Jonathan,

I’d suggest taking a look at the playground that I periodically send out to 
swift-evolution showing the current state of the python interop.  I just sent 
an update to the "Python Interop with Swift 4+” thread just now.  It works with 
unmodified Xcode 9, but includes comments showing what code could look like 
with the proposal in question.

> 1) How do operators work with this?  I saw you give an example of a+b for 
> python types, but I don’t see where either proposal bridges operators. (I 
> could easily have missed it though)

As Magnus points out, Swift 4 already supports overloading operators with 
dynamic behavior.  In the case of the playground, it looks like this:

public func +(lhs: PyVal, rhs: PyVal) -> PyVal {
  return lhs.call(member: "__add__", args: rhs)
}

This has all the “bad behavior” that people are concerned about: it could fail 
at runtime.  Despite the claims, Swift does not actually make an effort to 
prevent this, and that is an intentional part of its design.

> 2) What if I need two separate python libraries?  The code says ‘let np = 
> Python.import(“numpy”)’.  Are we supposed to make a separate variable for 
> each import?

Yes, that is traditional for python, which would typically look like:

import numpy as np
import pandas as pd 
import matplotlib.pyplot as plt

and the playground already supports (with no language extensions):

let np = Python.import(“numpy”)
let pd = Python.import(“pandas”)
let plt = Python.import(“matplotlib.pyplot”)

It turns out that languages everywhere have standardized on starting with a 
block of imports :-)


> 3) How will inter-op between Swift types and Python types work?  It looks 
> like you are just passing strings and integer constants to python functions. 
> Do they get converted automatically, or do we have to explicitly convert 
> them?  I am guessing this is using expressibleBy___ to work?

PyVal conforms to all of the ExpressibleBy protocols, so you can use literals 
with it freely.  You need an explicit (failable) conversion from a PyVal to Int 
(and other types that are PythonConvertible), and can use an explicit 
non-failable conversion from Int to PyVal if it is a variable.

The playground has a tutorial page which shows all this in action.

-Chris


> 
> Also, I would still really like to see a different coloring/styling for 
> methods which fall down to this protocol.
> 
> Thanks,
> Jon
> 
> 
> 
>> On Dec 4, 2017, at 7:30 PM, Chris Lattner via swift-evolution 
>>  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.  

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

[Joe DeCapo via swift-evolution]

> On Dec 6, 2017, at 7:41 AM, Vincent Esche via swift-evolution 
>  wrote:
> 
> If Swift had a rock-solid Generics system at this point and plenty of support 
> for Meta-Programming via hygienic example-based or procedural macros and/or 
> compiler plugins, then I'd be way less concerned about this feature getting 
> misused.
> 
> Alas while Swift's generics provide a nice basic foundation, they still have 
> big gaps in what can be expressed through them.
> And i'm not talking about HKT or any such more advanced use of types). I'm 
> talking about the basic stuff. Generic abstractions over type conversion. 
> Generic abstractions over arithmetic operators. This kind of stuff. Stuff, 
> that ironically would be necessary for a generic yet idiomatic implementation 
> of Linear Algebra algorithms in Swift.
> 
> I would prefer to get these gaps filled up before providing an orthogonal 
> feature that can easily be misinterpreted as a solution to the deficits in 
> Swift's generics system by someone coming from a dynamic language and/or 
> doesn't fully understand the use of generics.
> 
> We'd in essence be providing what looks like a solution in a time where 
> thousands of people are looking for workarounds to the limited expressiveness 
> of Swift's type system. That's like handing out bottles of Methanol for its 
> use as a household item in a time of severe drought. What could possibly go 
> wrong?

I think a more appropriate analogy would be to tools, rather than a toxic 
chemical during times of drought (I would hope the DynamicMemberLookup or 
DynamicCallable protocols won't result in any fatalities ;). Granted, I only 
have minimal woodworking experience so some details may be off. Let's say 
someone only has a hacksaw and circular saw. They're going to have to use these 
to do jobs that they shouldn't because they have no other option. Now, if 
someone is thinking about getting them a jigsaw, but says, "Well, they might 
use this jigsaw for things that a bandsaw or table saw would be more 
appropriate for, so let's wait until they get a bandsaw and table saw before 
giving them a jigsaw." Now they're still using inappropriate tools for the 
cases that a jigsaw would be suitable for. It would make more sense to give 
them the jigsaw to broaden the appropriate toolset, and then once they get the 
bandsaw and table saw they'll immediately stop using the jigsaw for those 
situations.

To me, the nastiest thing about the Swift standard library's internal 
implementation are gyb files. Admittedly, these solve a far more onerous 
problem than what this proposal is solving, but they're still a pretty ugly 
solution that come with problems of their own. But the people most excited and 
motivated to replace these with the appropriate solutions are the ones that 
wrote them or have to work with them 
(https://twitter.com/AirspeedSwift/status/936289022766333952). If people do end 
up using this as a workaround for some missing generics or type system feature, 
I imagine they would be the first to enthusiastically adopt the appropriate 
tools once they're available. And the great thing about software is that we can 
go back and actually change the tools we use to solve the same problem.

> It's also a completely different situation than what (from my understanding) 
> C# was in when they added `dynamic`.

I think this relates to a previous message I sent: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042018.html
 


Even with all the generic and reflective features in C# at the time, that 
author found it useful for simplifying code that didn't have anything to do 
with dynamic language support.


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

Apologies, I may have misunderstood you. What I wanted to say is that I see
no problem allowing "dangerous" stuff that may be abused. What we shouldn't
allow is features that are bug-prone, but this proposal is not that.

On Wed, Dec 6, 2017 at 10:48 AM, Tino Heth <2...@gmx.de> wrote:

>
> During the discussion, people emphasized that dynamic features would be
>> useful for more than Python interop, so if PyVal is the only way to get
>> those benefits… I have no fear of JS-Bridges utilizing Python, or
>> JSON-libraries build on top of PyVal — I just said that I don’t think it’s
>> possible to prevent all abuses (adding restrictions might even cause abuse).
>>
>>
> So what if they do this highly theoretical thing? Is this going to be a
> superior way of programming? If yes, then let's all do it! If not, then a
> superior solution will eventually emerge. Are you afraid that the community
> will be "tainted" by bad code? That Foundation will be rewritten with
> PyVals? And then you will be forced to write in PyVals too? What's the
> issue here?
>
> What’s wrong with my formulation when I write „I have no fear“ so that
> there are questions if I’m afraid afterwards? ;-)
> Once again: I just said that the proposed restriction won’t be able to
> prevent all abuse, which was claimed in an older post.
> So I“m so un-afraid, I’d even prefer the more „dangerous“ (I don’t think
> so) variant without artificial restrictions.
>
___
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]

> 6 Dec. 2017 16:51 Jonathan Hull via swift-evolution 
>  wrote:
> 
> Ok, I have changed my mind about the need for a marker, and will accept the 
> proposal as-is.  I realized that these dynamic member lookup types can just 
> be made inner types, and so I can easily create the .dynamic behavior in my 
> own code if I want under the current proposal.  I also realized that 
> requiring a marker would screw up the proxy use-case of this.
> 
> I do still have a couple of questions I am confused on:
> 
> 1) How do operators work with this?  I saw you give an example of a+b for 
> python types, but I don’t see where either proposal bridges operators. (I 
> could easily have missed it though)

Operators can be bridged using the existing Swift mechanisms, in this case 
operator overloading, so the proposal does not need to address operators.

> 2) What if I need two separate python libraries?  The code says ‘let np = 
> Python.import(“numpy”)’.  Are we supposed to make a separate variable for 
> each import?
> 
> 3) How will inter-op between Swift types and Python types work?  It looks 
> like you are just passing strings and integer constants to python functions. 
> Do they get converted automatically, or do we have to explicitly convert 
> them?  I am guessing this is using expressibleBy___ to work?

All of these will be up to the Python bridge implementation or implementations. 
This proposal is not a proposal of how to bridge Python and Swift, it is only 
enabling (not requiring) a decent syntax for these kinds of bridges.

/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

[Tino Heth via swift-evolution]

> During the discussion, people emphasized that dynamic features would be 
> useful for more than Python interop, so if PyVal is the only way to get those 
> benefits… I have no fear of JS-Bridges utilizing Python, or JSON-libraries 
> build on top of PyVal — I just said that I don’t think it’s possible to 
> prevent all abuses (adding restrictions might even cause abuse).
> 
> 
> So what if they do this highly theoretical thing? Is this going to be a 
> superior way of programming? If yes, then let's all do it! If not, then a 
> superior solution will eventually emerge. Are you afraid that the community 
> will be "tainted" by bad code? That Foundation will be rewritten with PyVals? 
> And then you will be forced to write in PyVals too? What's the issue here?
What’s wrong with my formulation when I write „I have no fear“ so that there 
are questions if I’m afraid afterwards? ;-)
Once again: I just said that the proposed restriction won’t be able to prevent 
all abuse, which was claimed in an older post.
So I“m so un-afraid, I’d even prefer the more „dangerous“ (I don’t think so) 
variant without artificial restrictions.___
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 Tue, Dec 5, 2017 at 6:56 PM, Tino Heth via swift-evolution <
swift-evolution@swift.org> wrote:

> No specific concerns, but I’m pretty sure developers writing real code
> will come up with ideas more bizarre than anything I can think of as an
> example.
>
> During the discussion, people emphasized that dynamic features would be
> useful for more than Python interop, so if PyVal is the only way to get
> those benefits… I have no fear of JS-Bridges utilizing Python, or
> JSON-libraries build on top of PyVal — I just said that I don’t think it’s
> possible to prevent all abuses (adding restrictions might even cause abuse).
>
>
So what if they do this highly theoretical thing? Is this going to be a
superior way of programming? If yes, then let's all do it! If not, then a
superior solution will eventually emerge. Are you afraid that the community
will be "tainted" by bad code? That Foundation will be rewritten with
PyVals? And then you will be forced to write in PyVals too? What's the
issue here?
___
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

[Jonathan Hull via swift-evolution]

Ok, I have changed my mind about the need for a marker, and will accept the 
proposal as-is.  I realized that these dynamic member lookup types can just be 
made inner types, and so I can easily create the .dynamic behavior in my own 
code if I want under the current proposal.  I also realized that requiring a 
marker would screw up the proxy use-case of this.

I do still have a couple of questions I am confused on:

1) How do operators work with this?  I saw you give an example of a+b for 
python types, but I don’t see where either proposal bridges operators. (I could 
easily have missed it though)

2) What if I need two separate python libraries?  The code says ‘let np = 
Python.import(“numpy”)’.  Are we supposed to make a separate variable for each 
import?

3) How will inter-op between Swift types and Python types work?  It looks like 
you are just passing strings and integer constants to python functions. Do they 
get converted automatically, or do we have to explicitly convert them?  I am 
guessing this is using expressibleBy___ to work?

Also, I would still really like to see a different coloring/styling for methods 
which fall down to this protocol.

Thanks,
Jon



> On Dec 4, 2017, at 7:30 PM, Chris Lattner via swift-evolution 
>  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

___
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 5, 2017, at 11:13 AM, Thorsten Seitz  wrote:
>> 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.
> 
> I just wanted to add that the single purpose of a static type system is to 
> ensure that the methods being called on a receiver are present at runtime and 
> take arguments of the types known at compile time.

Then, by your definition, Swift must not have a static type system.   Two 
examples:

x.b   // when x is an IUO
a + b// as implemented today in the Python bridge prototype I sent out.

-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 5, 2017, at 1:13 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> let result = dynamic x.foo.bar  // will crash if foo or bar are not present
> 
> let result = dynamic? x.foo.bar // will return nil if foo or bar are not 
> present
> 
> // will crash if foo or bar are not present
> let result = dynamic {
>   let y = x.foo.bar
>   let z = y.baz(42)
>   return z.zork()
> }
> 
> // will return nil if foo or bar are not present
> let result = dynamic? {
>   let y = x.foo.bar
>   let z = y.baz(42)
>   return z.zork()
> } 

As other people have pointed out, the behavior of something conforming to these 
protocols in no way implies that they crash if lookup fails. That is up to the 
implementer, and I assume most, if not all, will choose sane defaults 
(optional/throws) rather than just crashing.

But I think the main thing missing from this is where `x` came from. As I think 
Chris pointed out before, these values have to come from somewhere. If you have 
no idea what the type of the variable you're dealing with is and what its 
intended behavior might be, then I don't understand how you could even write 
this code in the first place.___
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]

> 6 Dec. 2017 04:13 Thorsten Seitz  wrote:
> 
> I just wanted to add that the single purpose of a static type system is to 
> ensure that the methods being called on a receiver are present at runtime and 
> take arguments of the types known at compile time. Of course the type system 
> does not guarantee that those calls to not fail. Even in Haskell there is no 
> guarantee that a function call does not fail as it allows partial patterns 
> (therefore `head []` crashes). Or a function call might enter an infinite 
> loop. But, to repeat, the type system guarantees that the method or member 
> itself will be present.
> 
> Therefore I cannot follow the argument that it follows from the possible 
> failure of a Swift method or member access that it is ok or even a comparable 
> type of failure if the method or member itself is not present. This would 
> imply that Swift’s static type system is unnecessary. Why check for the 
> presence of a method or member if calling it or accessing it might fail 
> anyway? No, I do not buy that argument. And I do not think that I have to 
> provide examples where a static type system is of help.

SOURCE MUSIC: "Soothe me"

Program crashes.

PROGRAMMER
What? What did I do?

RUNTIME
You failed to call a method correctly.

PROGRAMMER
The method was present, sir.


By your reasoning, this code would be ok:

class Example {
var a: Int { return values["a"]! }
var b: Int { return values["b"]! }
var c: Int { return values["c"]! }
var d: Int { return values["d"]! }
…
}

(which I believe is more or less equivalent to what has been suggested by some, 
but by enumerating all the dynamic members that seem to exist)

but not

class Example: DynamicMemberLookupProtocol {
   subscript(dynamicMember: String) -> Int {
return values[dynamicMember]!
   }
}

> The remaining question therefore is whether it is ok to remove the static 
> type system for certain isolated use cases and that might be the case. But I 
> like others would prefer if those use cases would be isolated somehow 
> visually. Someone proposed to require `dynamic` before expressions containing 
> dynamic member lookups similar to `try`, with the additional option to 
> enclose a whole block into `dynamic { … }` to express the same as prefixing 
> each expression with `dynamic`. I still think this has merit:
> 
> 
> let result = dynamic x.foo.bar  // will crash if foo or bar are not present
> 
> let result = dynamic? x.foo.bar // will return nil if foo or bar are not 
> present
> 
> // will crash if foo or bar are not present
> let result = dynamic {
>   let y = x.foo.bar
>   let z = y.baz(42)
>   return z.zork()
> }
> 
> // will return nil if foo or bar are not present
> let result = dynamic? {
>   let y = x.foo.bar
>   let z = y.baz(42)
>   return z.zork()
> } 
> 

Which is already possible with the proposal, using the existing "throw" 
mechanism in Swift.

/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

[Joe DeCapo via swift-evolution]

> On Dec 5, 2017, at 5:47 AM, Benjamin G  wrote:
> 
> About C#, in which i did program a few years ago (but before dynamic was in 
> the language), it already had powerful metaprogramming and introspection 
> capabilities, as well as very convenient  generics and interfaces ( easier to 
> work with than what swift offers today, but that was a long time ago so my 
> memory may be wrong). So, in some way, the potential for abusing dynamic or 
> "stringly typed" programming was a lot lower.

I find this perspective interesting because one of the articles I linked to on 
`dynamic` explicitly pointed out how it made some code far clearer than using 
reflection.

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

The example code using reflection:
public class ReflectiveTester : Tester
{

static void WritePropertyReflectively(object instance, string propertyName)
{
Type type = instance.GetType();
PropertyInfo propertyInfo = type.GetProperty(propertyName);
if (propertyInfo == null)
Console.WriteLine("Property \"{0}\" not found, propertyInfo " + 
  "is null\r\npropertyInfo.GetValue(...) will 
result " + 
  "in a NullReferenceException", propertyName);
else
Console.WriteLine(propertyInfo.GetValue(instance, null));
}

static void CallMethodReflectively(object instance, string methodName)
{
Type type = instance.GetType();
MethodInfo methodInfo = type.GetMethod(methodName);
if (methodInfo == null)
Console.WriteLine("Method \"{0}\" not found, " + 
  "methodInfo set to null\r\nmethodInfo.Invoke(...) 
" + 
  "will result in a NullReferenceException", 
methodName);
else
methodInfo.Invoke(instance, null);
}

static void WriteClassDetails(object instance)
{
Type type = instance.GetType();
WritePropertyReflectively(instance, "Property");
CallMethodReflectively(instance, "Method");
}
}

The example code using `dynamic`:
public class DynamicTester : Tester
{
void WriteClassDetails(dynamic instance)
{
try
{
   Console.WriteLine(instance.Property);
   instance.Method();
}
catch (RuntimeBinderException ex)
{
ErrorWriters.WriteRuntimeBinderException(ex);
}
}
}
And a quote from the article:
> One thing to conclude on is that this is not less "OO" than the reflective 
> call; it is directly equivalent, but it has a neat syntax and less obtuse 
> exception mechanism. If viewed this way, the addition of dynamicis a large 
> benefit, even before the dynamic language support is considered.


As I've said, I'm as far from a C# expert as they come, but the C# devs seem to 
really appreciate this feature and it doesn't appear to have been abused in the 
way people here seem to fear for the proposed protocols.___
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 11:24 PM, C. Keith Ray  wrote:
> 
> 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.)

Yeah, my main point was that things like autocompletion shouldn't really be a 
huge issue for this proposal. Even if we could match the state of the art in 
Python, it still would be inferior to the state of the art in Swift.

I've heard lots of good things about C# and the tooling around it, but being 
primarily a Mac user I've yet to find time to spend on a project in it. I 
definitely wouldn't be against trying it out some day :)___
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

[Letanyan Arumugam via swift-evolution]

I see that this feature is fully type safe and has behaviour that is precedent 
in the language today (It is just sugar after all). I still feel like it is not 
safe by default and doesn’t discourage the use dynamic programming over static.

Obviously for the latter if Swift doesn’t/shouldn’t have a preference 
between the two then by all means disregard as a reason for this design.

A way I see to accomplish both of these simultaneously is to have types that 
conform to DynamicMemberLookup is to force them to write subscripts that return 
optionals (and later throws if that ever gets support). To get return types 
that aren’t Optional a type would have to use a @unchecked attribute on the 
protocol conformance.

For Example:

enum JSON : DynamicMemberLookup {
subscript(dynamicMember: String) -> JSON {
...
}
}

would be a compile error, where as:

[*]
enum JSON : @unchecked DynamicMemberLookup {
subscript(dynamicMember: String) -> JSON {
...
}
}

OR

enum JSON : DynamicMemberLookup {
subscript(dynamicMember: String) -> JSON? {
...
}
}


would work fine.

I think one should also be able to override @unchecked and make conforming 
types checked.
So following on from the code example [*] if I were to write

extension JSON : @checked DynamicMemberLookup {}

then later dynamic member lookups would wrap the results in an optional.

Supporting this the other way (make a type unchecked) might not be ideal since 
the author of the type saw it unfit to have it unchecked and we should probably 
respect that.


I’m aware of #3 of “Reducing Potential Abuse” in the proposal however that 
option is not well expanded. So I’m not sure if this falls into that.

-Letanyan



___
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

[Alejandro Martinez via swift-evolution]

> I tried to recreate a dynamic BaseDynamicObject based on dictionaries and 
> your new protocols, but it's pretty hard without the finished implementation 
> (i will try to recompile swift using your pull request wheneve i got the 
> time, if i feel people are sincerely interested).

Not sure how relevant it is for the conversation but for cases like
this it maybe would be interesting to provide a swift toolchain from
the branch that can be easily used in Xcode to play around with it?
Now that an implementation is required for proposals this doesn't seem
that far fetched and it would allow the community to play a little
before deciding :)


For the rest of the conversation, I also have concerns on this being
misused and polluting our beloved language. And yeha, we have +, array
subscripting and fatalErrors that can be as bad but for some reason
(and yeha, we're just talking about feelings not real data so this is
noise, sorry for that) it's not really an issue in the real world. For
the AnyObject part I really don't see the argument there as I think I
don't really see it on App development and is just to interoperate
with a language available in Apple platforms, so it a really special
case that a lot of the community doesn't even use, specially when
people uses Swift in more platforms.

That said, for the ones that mention that we need to add special
syntax to make the possible failure of this calls I would argue that
the proposal already gives you a way to do it. When implementing a
bridge you can simply make your subscript throw or return optionals,
up to you. Also by not allowing conformance in extensions we avoid
weird issues (but i don't see a reason to use a superclass for that).

So yeha, in summary, I really like the proposal, specially with all
the changes that have been happening in the past few days. I'm still a
little afraid that this endsup resulting in a bad movement, but I
haven't agreed with others things accepted in evolution and nothing
has happened yet ¯\_(ツ)_/¯ Also, I love to see Swift getting more and
more powerful, and this is definitely a big deal.

these are my thoughts, thanks Chris for the proposal and the rest for
the great conversation ^^


On Tue, Dec 5, 2017 at 11:48 AM, Benjamin G via swift-evolution
 wrote:
>
>
> On Tue, Dec 5, 2017 at 4:30 AM, Chris Lattner via swift-evolution
>  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 

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

[C. Keith Ray via swift-evolution]

static type checking is no guarantee of program correctness. 

you can take a correct, functioning program in Java, for example, strip out all 
the type declarations and change the syntax to Groovy, and still have a 
correct, functioning program.

(if you avoid methods overloaded on parameter type)

with polymorphism via protocols, classes, etc., we don't have guarantees that 
the method invoked at runtime is actually going to behave correctly because 
behavior != type. 

polymorphism gives us advantages that make up for the lack of determinism.

the *code* calling a method should not have to care whether the object is using 
static dispatch, dynamic dispatch, or even remote-procedure calls. I kinda miss 
Objective-C's "Dynamic Objects" proxy objects which could forward method calls 
across process boundaries and over networks. 

obviously the *programmer* cares about additional failure cases involved for 
remote proxies, but there's no reason for different *syntax*.

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 5, 2017, at 11:13 AM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
>>> Am 03.12.2017 um 20:04 schrieb Magnus Ahltorp via swift-evolution 
>>> :
>>> 
>>> 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.
> 
> I just wanted to add that the single purpose of a static type system is to 
> ensure that the methods being called on a receiver are present at runtime and 
> take arguments of the types known at compile time. Of course the type system 
> does not guarantee that those calls to not fail. Even in Haskell there is no 
> guarantee that a function call does not fail as it allows partial patterns 
> (therefore `head []` crashes). Or a function call might enter an infinite 
> loop. But, to repeat, the type system guarantees that the method or member 
> itself will be present.
> 
> Therefore I cannot follow the argument that it follows from the possible 
> failure of a Swift method or member access that it is ok or even a comparable 
> type of failure if the method or member itself is not present. This would 
> imply that Swift’s static type system is unnecessary. Why check for the 
> presence of a method or member if calling it or accessing it might fail 
> anyway? No, I do not buy that argument. And I do not think that I have to 
> provide examples where a static type system is of help.
> 
> The remaining question therefore is whether it is ok to remove the static 
> type system for certain isolated use cases and that might be the case. But I 
> like others would prefer if those use cases would be isolated somehow 
> visually. Someone proposed to require `dynamic` before expressions containing 
> dynamic member lookups similar to `try`, with the additional option to 
> enclose a whole block into `dynamic { … }` to express the same as prefixing 
> each expression with `dynamic`. I still think this has merit:
> 
> 
> let result = dynamic x.foo.bar  // will crash if foo or bar are not present
> 
> let result = dynamic? x.foo.bar // will return nil if foo or bar are not 
> present
> 
> // will crash if foo or bar are not present
> let result = dynamic {
>   let y = x.foo.bar
>   let z = y.baz(42)
>   return z.zork()
> }
> 
> // will return nil if foo or bar are not present
> let result = dynamic? {
>   let y = x.foo.bar
>   let z = y.baz(42)
>   return z.zork()
> } 
> 
> 
> It allows to clearly demarcate the border between regions which are fully 
> statically type 

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

[BJ Homer via swift-evolution]

> On Dec 5, 2017, at 12:13 PM, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> let result = dynamic x.foo.bar  // will crash if foo or bar are not present
> 
> let result = dynamic? x.foo.bar // will return nil if foo or bar are not 
> present

Under the proposal given here, the compiler doesn’t know what will happen when 
“foo” or “bar” are not present. This proposal does not even require the 
implementation to report if a member is present or not, and there is certainly 
no guarantee of a crash in such a case. The only thing the compiler knows is 
that subscript(dynamicMember:) will be called.

Consider the following implementation:
 
struct PyVal: DynamicMemberLookupProtocol {

subscript(dynamicMember: String) -> PyVal? {
if let pythonMember = python_c_api.get(dynamicMember) {
return PyVal(pythonMember)
}
else {
return nil
}
}
}

let result = x.foo?.bar

There is no crashing here; result will be an optional type, and will be nil if 
the requested property does not exist. Some other use of 
DynamicMemberLookupProtocol might accept any value, and just log it to a file! 
In that case, neither crashing nor returning an optional is required.

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

[Howard Lovatt via swift-evolution]

+1 for Thorsten’s `dynamic` and `dynamic?`.

-- Howard. 

> On 6 Dec 2017, at 6:13 am, Thorsten Seitz via swift-evolution 
>  wrote:
> 
> 
>>> Am 03.12.2017 um 20:04 schrieb Magnus Ahltorp via swift-evolution 
>>> :
>>> 
>>> 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.
> 
> I just wanted to add that the single purpose of a static type system is to 
> ensure that the methods being called on a receiver are present at runtime and 
> take arguments of the types known at compile time. Of course the type system 
> does not guarantee that those calls to not fail. Even in Haskell there is no 
> guarantee that a function call does not fail as it allows partial patterns 
> (therefore `head []` crashes). Or a function call might enter an infinite 
> loop. But, to repeat, the type system guarantees that the method or member 
> itself will be present.
> 
> Therefore I cannot follow the argument that it follows from the possible 
> failure of a Swift method or member access that it is ok or even a comparable 
> type of failure if the method or member itself is not present. This would 
> imply that Swift’s static type system is unnecessary. Why check for the 
> presence of a method or member if calling it or accessing it might fail 
> anyway? No, I do not buy that argument. And I do not think that I have to 
> provide examples where a static type system is of help.
> 
> The remaining question therefore is whether it is ok to remove the static 
> type system for certain isolated use cases and that might be the case. But I 
> like others would prefer if those use cases would be isolated somehow 
> visually. Someone proposed to require `dynamic` before expressions containing 
> dynamic member lookups similar to `try`, with the additional option to 
> enclose a whole block into `dynamic { … }` to express the same as prefixing 
> each expression with `dynamic`. I still think this has merit:
> 
> 
> let result = dynamic x.foo.bar  // will crash if foo or bar are not present
> 
> let result = dynamic? x.foo.bar // will return nil if foo or bar are not 
> present
> 
> // will crash if foo or bar are not present
> let result = dynamic {
>   let y = x.foo.bar
>   let z = y.baz(42)
>   return z.zork()
> }
> 
> // will return nil if foo or bar are not present
> let result = dynamic? {
>   let y = x.foo.bar
>   let z = y.baz(42)
>   return z.zork()
> } 
> 
> 
> It allows to clearly demarcate the border between regions which are fully 
> statically type checked and those where the static type system be only 
> partially available (depending on the types of the respective receivers) 
> while not being very intrusive due to the block notation. 
> Of course I can still have a mixture of static and dynamic member accesses 
> _within_ a dynamic block but at least I know that when I am outside of such a 
> block there won’t be any dynamic member accesses. None. Zero.
> 
> -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] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Thorsten Seitz via swift-evolution]

> Am 03.12.2017 um 20:04 schrieb Magnus Ahltorp via swift-evolution 
> :
> 
>> 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.

I just wanted to add that the single purpose of a static type system is to 
ensure that the methods being called on a receiver are present at runtime and 
take arguments of the types known at compile time. Of course the type system 
does not guarantee that those calls to not fail. Even in Haskell there is no 
guarantee that a function call does not fail as it allows partial patterns 
(therefore `head []` crashes). Or a function call might enter an infinite loop. 
But, to repeat, the type system guarantees that the method or member itself 
will be present.

Therefore I cannot follow the argument that it follows from the possible 
failure of a Swift method or member access that it is ok or even a comparable 
type of failure if the method or member itself is not present. This would imply 
that Swift’s static type system is unnecessary. Why check for the presence of a 
method or member if calling it or accessing it might fail anyway? No, I do not 
buy that argument. And I do not think that I have to provide examples where a 
static type system is of help.

The remaining question therefore is whether it is ok to remove the static type 
system for certain isolated use cases and that might be the case. But I like 
others would prefer if those use cases would be isolated somehow visually. 
Someone proposed to require `dynamic` before expressions containing dynamic 
member lookups similar to `try`, with the additional option to enclose a whole 
block into `dynamic { … }` to express the same as prefixing each expression 
with `dynamic`. I still think this has merit:


let result = dynamic x.foo.bar  // will crash if foo or bar are not present

let result = dynamic? x.foo.bar // will return nil if foo or bar are not present

// will crash if foo or bar are not present
let result = dynamic {
let y = x.foo.bar
let z = y.baz(42)
return z.zork()
}

// will return nil if foo or bar are not present
let result = dynamic? {
let y = x.foo.bar
let z = y.baz(42)
return z.zork()
} 


It allows to clearly demarcate the border between regions which are fully 
statically type checked and those where the static type system be only 
partially available (depending on the types of the respective receivers) while 
not being very intrusive due to the block notation. 
Of course I can still have a mixture of static and dynamic member accesses 
_within_ a dynamic block but at least I know that when I am outside of such a 
block there won’t be any dynamic member accesses. None. Zero.

-Thorsten

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

>> Also, I don’t think anything can prevent all abuses (it’s an subjective 
>> classification anyways) — people might just use PyVals because dynamic 
>> behavior, and that would imho be a huge abuse.
> 
> Can you give an example of how someone would use such a PyVal to do something 
> other than interoperate with Python? I’m having trouble imagining what your 
> concern is. 

No specific concerns, but I’m pretty sure developers writing real code will 
come up with ideas more bizarre than anything I can think of as an example.

During the discussion, people emphasized that dynamic features would be useful 
for more than Python interop, so if PyVal is the only way to get those 
benefits… I have no fear of JS-Bridges utilizing Python, or JSON-libraries 
build on top of PyVal — I just said that I don’t think it’s possible to prevent 
all abuses (adding restrictions might even cause abuse).

___
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

[Ondrej Barina via swift-evolution]

+1 for the proposal

Ondrej Barina

On Tue, Dec 5, 2017 at 3:16 PM, BJ Homer via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Dec 5, 2017, at 7:06 AM, Tino Heth via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> Also, I don’t think anything can prevent all abuses (it’s an subjective
> classification anyways) — people might just use PyVals because dynamic
> behavior, and that would imho be a huge abuse.
>
>
> Can you give an example of how someone would use such a PyVal to do
> something other than interoperate with Python? I’m having trouble imagining
> what your concern is.
>
> Specifically in the case of PyVal, I imagine it would already be
> hard-coded to call into Python for any dynamic lookup, so I don’t see how
> one could use “just use PyVal because dynamic behavior”. Are you saying
> that someone would just write all their code in a Python library, and then
> call into it from Swift?
>
> -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] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[BJ Homer via swift-evolution]

> On Dec 5, 2017, at 7:06 AM, Tino Heth via swift-evolution 
>  wrote:
> 
> Also, I don’t think anything can prevent all abuses (it’s an subjective 
> classification anyways) — people might just use PyVals because dynamic 
> behavior, and that would imho be a huge abuse.

Can you give an example of how someone would use such a PyVal to do something 
other than interoperate with Python? I’m having trouble imagining what your 
concern is. 

Specifically in the case of PyVal, I imagine it would already be hard-coded to 
call into Python for any dynamic lookup, so I don’t see how one could use “just 
use PyVal because dynamic behavior”. Are you saying that someone would just 
write all their code in a Python library, and then call into it from Swift?

-BJ

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

> "Have the compiler specifically bless individual well-known types, e.g. 
> Python.PyVal (or whatever it is eventually named) by baking in awareness of 
> these types into the compiler. Such an approach would require a Swift 
> evolution proposal to add a new type that conforms to this."
> +1
I have strong bias against special cases in the compiler (well, actually, 
against special cases in general ;-).
Imho it’s preferable to keep the compiler simple, and change it only for thinks 
you can’t do with a library.

> I think there are a very finite number of programming languages Swift would 
> like to have this kind of interop with, and i think having every new case 
> reach into core team would also be a good opportunity to reevaluate that part 
> of the language.
I’m pro reevaluation, but what could be the outcome? This process only makes 
sense if it is an option to roll back changes that don’t work as well as 
expected.

> IIUC, this is also the most controlled version of the proposal, and it 
> prevents all abuses, while enabling the most seamless experience for python 
> developers. So, it looks perfect to me.

I may have missed some changes in direction, but afair, it was a strong point 
in the early revisions of the proposals that the suggested changes are useful 
in general, and not Python-specific…
Also, I don’t think anything can prevent all abuses (it’s an subjective 
classification anyways) — people might just use PyVals because dynamic 
behavior, and that would imho be a huge abuse.___
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

[Michel Fortin via swift-evolution]

> Le 5 déc. 2017 à 0:43, C. Keith Ray via swift-evolution 
>  a écrit :
> 
> 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.

Most people would expect Java language bindings to be strongly typed. That 
would require an approach where the Java APIs can be introspected at compile 
time.

-- 
Michel Fortin
https://michelf.ca

___
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

[Abe Schneider via swift-evolution]

I use python on a daily basis for scientific computing (PyTorch, Matplotlib, 
Numpy, Scipy, scikits-learn, etc.). Python is great for doing quick projects, 
but certain design features of the language make it less ideal for large 
projects (e.g. whitespace, weak typing, speed, etc.). Swift shares many of the 
nice qualities Python has but without some of the warts.

To answer your question, I think anyone who needs to integrate their algorithm 
into larger projects and/or on hardware care about moving away from Python. 

I think trying to include Python libraries makes sense. Julia did the same 
thing, which allowed them to grow their user base very quickly (e.g. being able 
to use Matplotlib in Julia was a huge win). I believe the way Julia imports 
Python libraries is via its extremely powerful (and complex) macro system.

While using Python via Swift is a great way to use already written libraries, 
my preference would be to eventually write everything in Swift (trying to debug 
across languages can be painful). I did (a while ago) write a Tensor library 
for Swift, but ran into some issues when trying to make it run both on the CPU 
and GPU. A new approach I’m considering is to instead wrap a pre-existing C 
library.

My two cents, as the question of users was brought up.

A

> On Dec 4, 2017, at 12:15 PM, Tino Heth via swift-evolution 
>  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.
> 
> ___
> 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

[Benjamin G via swift-evolution]

On Tue, Dec 5, 2017 at 12:48 PM, Benjamin G via swift-evolution <
swift-evolution@swift.org> wrote:

>
>
> On Tue, Dec 5, 2017 at 4:30 AM, Chris Lattner via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> > On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution <
>> swift-evolution@swift.org> 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-refe
>> rence/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.
>>
>
> For what i'm concerned, let's be very clear : i do not consider my
> personal opinion to matter AT ALL compared to what people like you, who
> code compilers for a living, think. And i feel even more embarrassed
> participating in that conversation since it's about a language you
> invented. I've only done it because people in the core team said it would
> be interesting.
> Now, the only area where I may have more experience than people like you,
> is working with the average programmer, in the industry. And my personal
> experience shows that what a language doesn't enable is as important as
> what it enables (because every feature that can be abused will be,
> eventually and in ways nobody can expects).
>
> Regarding your proposal regarding the impact it could have on pure swift,
> i think it comes down to letting the developer masquerade dictionaries into
> proper structs or classes. I tried to recreate a dynamic BaseDynamicObject
> based on dictionaries and your new protocols, but it's pretty hard without
> the finished implementation (i will try to recompile swift using your pull
> request wheneve i got the time, if i feel people are sincerely interested).
> The "benevolent" purpose for doing that would be anything regarding
> mocking, proxying, mixins objects and their properties. There are various
> examples of those patterns in every dynamic languages.
>
> About C#, in which i did program a few years ago (but before dynamic was
> in the language), it already had powerful metaprogramming and introspection
> capabilities, as well as very convenient  generics and interfaces ( easier
> to work with than what swift offers today, but that was a long time ago so
> my memory may be wrong). So, in some way, the potential for abusing dynamic
> or "stringly typed" programming was a lot lower.
>
>
>
>
>>
>> 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 

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

[Benjamin G via swift-evolution]

On Tue, Dec 5, 2017 at 4:30 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> > On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution <
> swift-evolution@swift.org> 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.
>

For what i'm concerned, let's be very clear : i do not consider my personal
opinion to matter AT ALL compared to what people like you, who code
compilers for a living, think. And i feel even more embarrassed
participating in that conversation since it's about a language you
invented. I've only done it because people in the core team said it would
be interesting.
Now, the only area where I may have more experience than people like you,
is working with the average programmer, in the industry. And my personal
experience shows that what a language doesn't enable is as important as
what it enables (because every feature that can be abused will be,
eventually and in ways nobody can expects).

Regarding your proposal regarding the impact it could have on pure swift, i
think it comes down to letting the developer masquerade dictionaries into
proper structs or classes. I tried to recreate a dynamic BaseDynamicObject
based on dictionaries and your new protocols, but it's pretty hard without
the finished implementation (i will try to recompile swift using your pull
request wheneve i got the time, if i feel people are sincerely interested).
The "benevolent" purpose for doing that would be anything regarding
mocking, proxying, mixins objects and their properties. There are various
examples of those patterns in every dynamic languages.

About C#, in which i did program a few years ago (but before dynamic was in
the language), it already had powerful metaprogramming and introspection
capabilities, as well as very convenient  generics and interfaces ( easier
to work with than what swift offers today, but that was a long time ago so
my memory may be wrong). So, in some way, the potential for abusing dynamic
or "stringly typed" programming was a lot lower.




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

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