[swift-evolution] Ad hoc enums / options

[Brent Royal-Gordon]

> 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