> On Nov 20, 2017, at 1:41 PM, David Waite <da...@alkaline-solutions.com> wrote: > > In ruby, parens are optional. So, > > v = foo.value > > and > > v = foo.value() > > are identical.
Ok, I wasn’t aware of that. It isn’t clear that we’d want to carry that into a “Ruby APIs when used in Swift” though! One could definitely argue against the former calling a method, even if that is possible in Ruby APIs. > There dot syntax is only used for method invocation, so there is no external > access to instance variables without some twiddling; similarly getting access > to a Proc/lambda/Method requires twiddling in Ruby (although there are > shortcuts in normal use, like Symbol#to_proc) I think you’re missing the idea here: the idea isn’t to provide exactly syntax mapping of Ruby (or Python) into Swift, it is to expose the underlying semantic concepts in terms of Swift’s syntax. In the case of Python, there is a lot of direct overlap, but there is also some places where Swift and Python differs (e.g. Python slicing syntax vs Swift ranges). In my opinion, Swift syntax wins here, we shouldn’t try to ape a non-native syntax in Swift. > For mapping to Swift, I would say that parens are needed; we can’t guess > whether a `foo.bar` is meant to be asking for the value of attribute bar or a > reference to method bar. +1 > More difficult would be the use of ‘=‘, ‘!’, and ‘?’ - all legal in Ruby > method names as suffixes. Using those would require backquotes: x.`what?`() -Chris _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
