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

Howard Lovatt howard.lovatt at gmail.com
Thu Jan 28 01:38:15 CST 2016


As an aside: I think that iterator is a bad example because iterator itself
is undefined as to whether it is single or multi pass. In Java the two
concepts are seperate; an iterator is always multi pass and a stream is
maybe multi pass but is treated as single pass unless you are really sure
it is multi pass (it generates a runtime error if it is single pass and you
attempt twice). This is probably a better approach and in Swift terms it
would be sequence.iterator and sequence.stream() (to remind you that stream
is probably single pass).

Back to the main topic: If we take reverse as an example then I think
sequence.reverse() reads well because you cannot iterate twice.

On 28 January 2016 at 16:46, David Waite <david at alkaline-solutions.com>

> > 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!)
> -DW

  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160128/ddd7fafc/attachment.html>

More information about the swift-evolution mailing list