> On May 31, 2016, at 12:35 PM, Matthew Johnson <matt...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
