> On May 31, 2016, at 2:04 PM, Erica Sadun <[email protected]> wrote: > >> >> On May 31, 2016, at 12:35 PM, Matthew Johnson <[email protected] >> <mailto:[email protected]>> 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.
If you are not allowing callers to store their argument in a variable then I am 100% opposed to this. That would the first case in Swift where you *MUST* provide a literal argument when calling a function, and *CANNOT* provide a value you store in a variable (possibly something you receive as an argument from somewhere else). Why would we want to restrict the flexibility of callers in that way? > > -- E
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
