<div dir="ltr"><div>I support the original proposal. My assumption is that (.fit|.fill) is the name of a type that can be used anywhere types can be named.</div><div><br></div>I think the concern about duplicates is misplaced. If the same developer creates the scaleAndCrop function and the rect function, they may decide to extract the enum type to a named enum when they see the second use. If they don't, it's because they're in the flow - no harm results from naming this type in two places. They have the opportunity to reconsider their decision if they add cases later.<div><br></div><div>Ad hoc enums are to named enums as closures are to funcs: closures and ad hoc enums both increase developer flow at the risk that the developer needs to refactor later to maximize reuse and minimize duplication. Allowing developers to make these trade-offs according to their own preference is a good thing.<div><div><br></div><div>-- Callionica</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 31, 2016 at 2:20 PM, Brent Royal-Gordon via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> func scaleAndCropImage(<br>
> image: UIImage,<br>
> toSize size: CGSize,<br>
> operation: (.Fit | .Fill) = .Fit<br>
> ) -> UIImage {<br>
<br>
</span>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.<br>
<br>
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:<br>
<br>
func scaleAndCrop(image: UIImage, to size: CGSize, operation: (.fit | .fill) = .fit) -> UIImage {<br>
let drawingRect = rect(of: size, for: operation)<br>
return drawnImage(image, in: drawingRect)<br>
}<br>
<br>
private func rect(of size: CGSize, for operation: (.fit | .fill)) -> CGRect {<br>
<br>
Already we have one duplication; if we add .fillWidth and .fillHeight modes, we'll need to change signatures in two places.<br>
<br>
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.<br>
<br>
(It's also worth noting that this isn't suitable for options, because it creates an anonymous enum, not an anonymous option set.)<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>