[swift-evolution] Ad hoc enums / options

[Charlie Monroe]

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 at 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 at swift.org <mailto: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 <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 <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/725605db/attachment.html>