[swift-evolution] [Review] SE-0023 API Design Guidelines (when to use properties)

David Waite david at alkaline-solutions.com
Wed Jan 27 23:46:05 CST 2016

> On Jan 27, 2016, at 9:48 PM, Howard Lovatt <howard.lovatt at gmail.com> wrote:
> I would have no such qualms. To me array.iterator reads better that array.iterator().

I’d make the same argument as I did before for reverse(), except in this case the generator mutates state indirectly (the results of next() on two generators returned from the same sequence are not defined to be similar)

> There is precedence for this approach also; Scala. In Scala they go even further, if you declare a function with no args you can always call it without brackets. This works well in Scala and mixes well with their properties that are very similar to Swift properties (though different syntax).

Not surprising considering Scala’s functional influences. In a pure functional system, no input to a function means something is a constant.

In Ruby, the pattern to only really require parens to disambiguate an expression. The language allows ‘!’ to be used in a method signature to remind developers of side effects (or to disambiguate a non-mutating version, e.g. String#capitalize vs capitalize!)

This has been overloaded somewhat to indicate methods which would be expected to mutate and return a result are instead mutating and raising an exception on failure (e.g. ActiveRecord::Base#save vs save!)


More information about the swift-evolution mailing list