+1
-Thorsten
> 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
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
