[swift-evolution] Ad hoc enums / options

Christopher Kornher ckornher at me.com
Tue May 31 11:53:46 CDT 2016


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 <mailto: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 <mailto: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/6c379492/attachment.html>


More information about the swift-evolution mailing list