Same as Kevin. I like this pattern, but an implicit behavior of this sort doesn’t seem appropriate.
— Radek > On 20 Dec 2015, at 04:05, Kevin Ballard via swift-evolution > <[email protected]> wrote: > > 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 >> <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 >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
