[swift-evolution] Ad hoc enums / options

[Matthew Johnson]

I think I'm -1 on this.  It makes things easier for the implementer of the function and harder for the caller.  

It's not clear whether the caller could store an argument to pass in a variable, but if they could they would need to list out all cases in the type of the variable (unless these anonymous enums have structural subtyping).  This is fragile.  Any time that list changes all variable declarations will have to be updated.

Functions are implemented once and usually called more many times.  It's better for callers if you just write it like this:

enum FitOrFill { case fit, fill }
func scaleAndCropImage(
image: UIImage,
toSize size: CGSize,
operation: FitOrFill = .fit
) -> UIImage {

So unless these anonymous enums are structurally subtyped I think it's a bad idea.  And introducing structural subtyping here seems like a pretty large hammer for this use case.

Sent from my iPad

> On May 31, 2016, at 12:44 PM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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
> _______________________________________________
> 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/382b3049/attachment.html>