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 > <swift-evolution@swift.org> wrote: > > On 10 October 2017 at 07:02, Xiaodi Wu <xiaodi...@gmail.com > <mailto:xiaodi...@gmail.com>> 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 <tinoh...@me.com > <mailto:tinoh...@me.com>> 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 > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution David James
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
