> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> operation: (.Fit | .Fill) = .Fit
> ) -> UIImage {
As I said the last time this proposal came up, I think this is great right up
until the moment you need `operation` to be computed or kept in a variable.
Then you need to start copying your anonymous enum type all over your source,
and there's no central place to make changes. The same thing is true of tuples,
but tuples are easy to structure and destructure from individual values on the
spot; anonymous enums aren't really like that.
And this problem starts occurring *very* quickly. I mean, you've left
`scaleAndCropImage`'s implementation out. Imagine implementing it with a couple
helper functions, and you start to see this problem occurring:
func scaleAndCrop(image: UIImage, to size: CGSize, operation: (.fit |
.fill) = .fit) -> UIImage {
let drawingRect = rect(of: size, for: operation)
return drawnImage(image, in: drawingRect)
}
private func rect(of size: CGSize, for operation: (.fit | .fill)) ->
CGRect {
Already we have one duplication; if we add .fillWidth and .fillHeight modes,
we'll need to change signatures in two places.
In short, when you dig into this proposal and start thinking of use cases that
are even slightly less than completely trivial, I think the case for it falls
apart.
(It's also worth noting that this isn't suitable for options, because it
creates an anonymous enum, not an anonymous option set.)
--
Brent Royal-Gordon
Architechies
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
