IMO everyday app building would rarely need to use functions with discardable results. This is more an issue with libraries or frameworks that support a fluent interface (e.g. that return self) where an operator chain can be stopped at any point, unless it clearly doesn’t make sense, in which case @discardableResult would not be advised. I am building such a library. It has 200+ uses of @discardableResult and I don’t have a problem with it in it’s current form (especially since it can go on the line before the function). It’s an annotation for a specialized purpose, hence the very specific nomenclature.
> On Oct 10, 2017, at 7:48 PM, Mike Kluev via swift-evolution > <[email protected]> wrote: > > On 10 October 2017 at 07:02, Xiaodi Wu <[email protected] > <mailto:[email protected]>> wrote: > This idea was discussed long ago and the present design was selected. At this > point in Swift Evolution, source-breaking changes are in scope only if the > status quo is demonstrably harmful. > > changes like discussed are not necessarily source-breaking: you can allow > @discardableResult for a while (along with deprecating it at some point) in > addition to having a newer preferred way - should we decide there is a > preferred way. > > on Mon, 09 Oct 2017 20:07:13 +0200 Tino Heth <[email protected] > <mailto:[email protected]>> wrote: > As for the line-length, I don’t buy this argument, because placement of line > breaks is just personal preference, and keywords/annotations created by > gluing together two words should imho avoided wherever possible (not only > because the increased character count). > > +1. same here on both counts. multi-word compound and @ symbol makes names > ugly. it feels it was done intentionally to indicate a "temporary" "to be > cleaned later" nature of a feature (it is a very good choice for @objc) > > and if "fileprivate" is ugly because it is two words glued together (*) maybe > there is another name for it? just "file"? "domestic" ? > > Mike > (* the very concept of "file private" is a bit ugly from a traditional > languages perspective). > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution David James
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
