[swift-evolution] Ad hoc enums / options

[Charles Constant]

An enthusiastic +1 to Erica's suggestion.

While I also see the appeal of Chris Kornher's suggestion of giving the
enum a proper Type, I think Erica's syntax is more appropriate. I haven't
though through the implications of having an "anonymous enum" but since the
main use case is just to give functions a more convenient and legible way
to specify options, I think shorter is better.

I really like this proposal. It would result in a lot of Swift code, out
there in the world, being a little easier to read :)



On Tue, May 31, 2016 at 9:53 AM, Christopher Kornher via swift-evolution <
swift-evolution at swift.org> wrote:

> *Forwarding on behalf of Chris Kornher:*
>
> I think that this is a great idea. It would be nice to:
> 1) Have a standard way to generate these values from textual or other
> serialized representations.
> 2) A way to be able to store these vales (as preferences, for example)
>
> A simple way to do support this is to make these into full-fledged enums:
>  1) make these rawrepresentable string enums
>  2) give the type a name for use when needed: e.g.
> scaleAndCropImage.fitImage.options_t or perhaps, :
> scaleAndCropImage_fitImage_options_t enabling:  struct MyPreferenceStruct
> { .. var fitOptions: scaleAndCropImage_fitImage_options_t }
>
> Thinking about this a bit more, requiring a name like:
>
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> *operation: ScaleCropFitFitFill{.Fit | .Fill} = .Fit*
> ) -> UIImage {
> would be cleaner.
>
> - Chris
>
>
> On May 31, 2016, at 10:16 AM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Here's a function signature from some code from today:
>
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> *fitImage: Bool = true*
> ) -> UIImage {
>
>
> And here's what I want the function signature to actually look like:
>
> func scaleAndCropImage(
> image: UIImage,
> toSize size: CGSize,
> *operation: (.Fit | .Fill) = .Fit*
> ) -> UIImage {
>
>
> where I don't have to establish a separate enumeration to include ad-hoc
> enumeration-like semantics for the call. A while back, Yong hee Lee
> introduced anonymous enumerations (and the possibility of anonymous option
> flags) but the discussion rather died.
>
> I'm bringing it up again to see whether there is any general interest in
> pursuing this further as I think the second example is more readable,
> appropriate, and Swifty than the first, provides better semantics, and is
> more self documenting.
>
> Thanks for your feedback,
>
> -- Erica
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> 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/20160531/f7c7d499/attachment.html>