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 < [email protected]> 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 < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > 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
