> Am 03.12.2017 um 21:20 schrieb Karl Wagner via swift-evolution 
> <swift-evolution@swift.org>:
>> I believe that adding explicit syntax would be counterproductive to your 
>> goals, and would not make dynamic lookup syntax more clear.  I assume that 
>> you would also want the same thing for DynamicCallable too, and operator 
>> overloads, subscripts, and every other operation you perform on these 
>> values, since they all have the exact same behavior.
>> If we required some syntax even as minimal as “foo.^bar” and "baz^(42)”, 
>> that change would turn this (which uses runtime failing or IUO return values 
>> like AnyObject):
>>      let np = Python.import("numpy")
>>      let x = np.array([6, 7, 8])
>>      let y =  np.arange(24).reshape(2, 3, 4)
>>      let a = np.ones(3, dtype: np.int32)
>>      let b = np.linspace(0, pi, 3)
>>      let c = a+b
>>      let d = np.exp(c)
>>      print(d)
>> into:
>>      let np = Python.import("numpy")
>>      let b = np^.array^([6, 7, 8])
>>      let y =  np^.arange^(24)^.reshape^(2, 3, 4)
>>      let a = np^.ones^(3, dtype: np^.int32)
>>      let b = np^.linspace^(0, pi, 3)
>>      let c = a+^b
>>      let d = np^.exp^(c)
>> This does not improve clarity of code, it merely serves to obfuscate logic.  
>> It is immediately apparent from the APIs being used, the API style, and the 
>> static types (in Xcode or through static declarations) that this is all 
>> Python stuff.  When you start mixing in use of native Swift types like 
>> dictionaries (something we want to encourage because they are typed!) you 
>> end up with an inconsistent mismash where people would just try adding 
>> syntax or applying fixits continuously until the code builds.
> That’s not Swift. You just wrote a bunch of Python. For example, Swift has a 
> native Int32.+ operator which fails on overflow - does your example also do 
> that? Anybody’s guess! Does your numpy array conform to Collection? I guess 
> not, because it’s an opaque Python value.
> That’s exactly the kind of stuff I, as a user of the language, really don't 
> want to see mixed together with real Swift. I appreciate the need to use 
> functionality from libraries written in Python, but I don’t appreciate it 
> being so invisible and pervasive throughout the language. If you have a bunch 
> of Python logic, I’d prefer you wrote as much of it as possible in Python, 
> with as few bridging points to Swift as you can get away with. I remain 
> convinced that this design encourages the opposite - because, as you said 
> earlier, it’s “too good”.
> As for the point about Swift already including non-marked, 
> potentially-crashing operations (like the + operator, or Array subscripting): 
> nobody likes that behaviour! Whenever I come to a new Swift codebase, I 
> almost universally find that people have written their own “safe” Array 
> accessor which integrates bounds-checking and returns an Optional. The issue 
> has come up here many, many times for inclusion in the standard library. I 
> certainly would not use it as justification for adding more of those kinds of 
> unmarked, potentially-unsafe operations. Also, enough Swift developers know 
> about the Array subscript behaviour that the square brackets almost become a 
> marker, like “!”, of a potentially-failing operation. The same is not true of 
> the dot operator, in general.
> I also don’t agree with the comparisons to Objective-C/AnyObject dispatch. 
> It’s true that it’s unsafe to an extent, but it’s also orders of magnitude 
> safer than this sort of dispatch. Clang is integrated in to the compiler, and 
> can at least perform some rudimentary checking of method 
> signatures/selectors. This sort of dispatch provides absolutely no 
> protections whatsoever — is “arange” really a function? Is it not really a 
> typo for “arrange”? That’s something I need to Google. With regular Swift I 
> can assume that if the compiler allows it, there is a function called 
> “arange” somewhere, and all I need to worry about is whether the erased 
> AnyObject is of the correct type to respond to that message. And as I said 
> earlier, AnyObject is incredibly rare in practice anyway. So no, I don’t 
> agree that we should just keep lowering the safeguards; it’s like demolishing 
> your house because of one draughty door.
> What I could support, would be some kind of optional syntax, possibly with 
> some kind of associated scope which allows you omit it. Something like:
> // Normally, optionals are required.
> let result: PythonObject? = pythonObj.someProperty?.someFunction(1, 2, 3)
> // Within a special scope, you can omit them. The scope will bail at the 
> first lookup failure and return nil.
> let result: PythonObject? = Python {
>     return pythonObj.someProperty.someFunction(1, 2, 3)
> }
> Perhaps the “Python” object could conform to a protocol with an associated 
> type for the objects it can implicitly unwrap. There would be some additional 
> compiler work, for sure, but that’s secondary to a good language model IMO 
> (easy for me to say, I know).
> - Karl
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

swift-evolution mailing list

Reply via email to