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.
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. 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. -- Callionica On Tue, May 31, 2016 at 2:20 PM, Brent Royal-Gordon via swift-evolution < [email protected]> wrote: > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
