[swift-evolution] Ad hoc enums / options

Erica Sadun erica at ericasadun.com
Tue May 31 14:04:02 CDT 2016

> On May 31, 2016, at 12:35 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 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.

From the caller's point of view, the type must be inferable and exactly match a token listed in the declaration (which would also appear in Quick Help):

let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill)

You would not be able to assign `.fill` to a variable and use that for the operation value.

-- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160531/e8749d48/attachment.html>

More information about the swift-evolution mailing list