This kind of pattern (which I've always considered the "builder pattern") is useful in various circumstances, but I don't think it is reasonable to assume that it's the appropriate pattern to use by default for any mutating method.
I'd much rather see an explicit method cascade operator added (e.g. Dart's .. operator), which fulfills the same desire but without requiring any API or even ABI changes, and without adding the overhead of duplicating values all over the place (e.g. all the now-implicit-self return values that aren't actually used by the caller). -Kevin Ballard On Sat, Dec 19, 2015, at 09:21 AM, Tino Heth via swift-evolution wrote: > Hi there, > > this idea might be quite unconventional, but it is simple and wouldn't > break any existing code. Returning void has no use beside telling > "there is nothing to return" and makes it impossible to perform method > chaining, which drives popular systems like iostream and LINQ (the > concept was promoted by Martin Fowler as fluent interface - but > wikipedia has a good explanation on this: > https://en.wikipedia.org/wiki/Fluent_interface) One of its most > popular use cases is database access, which imho will become quite > important for Swift as it might gain popularity in the server domain. > It is useful in other areas as well, but I'll stick to databases in an > example: > > let kids = userDatabase.select(.name).where(.age < 18) > > This is already possible in Swift today, but with a simple change, it > could be much more fun: I guess void is the natural choice for a > default return value - what else is guaranteed to exist in a function? > For methods, on the other hand, there is a real object that is always > available: self. If self would be the default return value, we would > get method chaining for free in all places where we now stuck with > void - and whoever doesn't like the concept can still ignore the value > as he did with (). > > I have to admit that right now there is a proposal that wants to > sanction ignoring non-void return values with warnings, which would > interfere with this idea; but imho even in this case the workarounds > wouldn't be that complicated. > > So, please give feedback wether it is worth the burden of writing a > official proposal or start by creating a library with the current > toolset and try to prove the usefulness of fluent interfaces ;-) > > Best regards, Tino > > _________________________________________________ > 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
