[swift-evolution] Ad hoc enums / options

[Tony Allevato]

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160531/a9a4ac05/attachment.html>