Big +1. I had similar thoughts a while back when I was writing some C++ or Java code that had boolean arguments, and I found myself hating how non-documenting they were and I would contrive two-valued enums to make call sites look better. Having a crisp clean syntax for this would be fantastic and encourage people to write self-documenting APIs.
Having argument labels solves some of the problems that come along with boolean arguments, but "fitImage" is a great example where the false case ("not fit?") doesn't really convey enough information (or can convey misleading information). On Tue, May 31, 2016 at 9:17 AM Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > Here's a function signature from some code from today: > > func scaleAndCropImage( > image: UIImage, > toSize size: CGSize, > *fitImage: Bool = true* > ) -> UIImage { > > > And here's what I want the function signature to actually look like: > > func scaleAndCropImage( > image: UIImage, > toSize size: CGSize, > *operation: (.Fit | .Fill) = .Fit* > ) -> UIImage { > > > where I don't have to establish a separate enumeration to include ad-hoc > enumeration-like semantics for the call. A while back, Yong hee Lee > introduced anonymous enumerations (and the possibility of anonymous option > flags) but the discussion rather died. > > I'm bringing it up again to see whether there is any general interest in > pursuing this further as I think the second example is more readable, > appropriate, and Swifty than the first, provides better semantics, and is > more self documenting. > > Thanks for your feedback, > > -- Erica > > _______________________________________________ > 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