[swift-evolution] Ad hoc enums / options

[Callionica (Swift)]

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 <
swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160601/b5d45b1a/attachment.html>