I have mixed feelings about this since it may lead to redeclarations over and over of the same values instead of actually declaring an enum.
> On May 31, 2016, at 7:31 PM, Charles Constant via swift-evolution > <swift-evolution@swift.org> wrote: > > 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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
