<div dir="ltr"><div><div><div>I do not really have a strong opinion on whether this
feature should be added to the language, though I will say that if it
is, I do not see the need to enforce the visibility of failability on a language level. The feature as proposed is, as has been restated many times, entirely safe. A
sane language wrapper implemented using this would likely deal with
optionals at every corner, but the feature itself can, and in my opinion
should, be as generic as possible.<br><br></div>That said, I feel that this discussion has lacked mention of what is actually possible in Swift today. Sure, this:</div><div><br></div><div>>> let d = np.call(member: "array", args: Python.array(6, 7, 8),<br>>> kwargs: [("dtype", "i2")])</div><div><br></div>looks positively hideous, but with some operator cleverness, one can get things like:</div><div><br></div><div>val.."prop" // get property prop of val<br>val.."prop".."turboprop" // get property turboprop of property prop of val<br>val.."prop" <- newProp // set property prop of val to newProp<br>val.."prop".."func"..[arg1, arg2] // call function func of property prop of val with arguments (arg1, arg2)</div><div><br></div>to
compile, and indeed to do sensible things. I believe this sort of DSL-y
hacks already enabled by Swift should be taken into consideration when
assessing the necessity of this feature and the dynamic calling syntax
one.<div class="gmail-yj6qo gmail-ajU"><div id="gmail-:2f2" class="gmail-ajR" tabindex="0"><img class="gmail-ajT" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div><div class="gmail-ajR" tabindex="0"> -Pertti<br></div></div></div>