[swift-evolution] Ad hoc enums / options

Erica Sadun erica at ericasadun.com
Tue May 31 13:37:46 CDT 2016


>> I have two suggested “improvements”
>> 
>> 1) Make the enum String raw-representable. Name it somehow. This does not affect Erica’s original syntax.
>> 2) Force an explicit name.
>> 
>> class MyImage  {
>> 	func scaleAndCropImage(
>>     		image: UIImage,
>> 		toSize size: CGSize,
>> 		operation: ScaleCropFitFill{ .Fit | Fill} = .Fit
>> 
>>     	) -> UIImage {…}
>> }
>> 
>> would be equivalent to:
>> 
>> class MyImage  {
>>  	enum  ScaleCropFitFill {
>> 		case  Fit
>> 		case  Fill
>> 	} 
>> 
>> 	func scaleAndCropImage(
>> 		image: UIImage,
>> 		toSize size: CGSize,
>> 		operation: ScaleCropFitFill = .Fit
>> 	) -> UIImage {…}
>> }

This is not the direction I'm hoping to move in.

If an enumeration is to be used in more than one place, it should be a proper enumeration. Swift already offers dependent type support.  Single-point ad-hoc enumerations create better semantics for moving from if statements that test on Boolean values to switch statements that test on phrases, without creating dependencies on other types. As Tony A points out, 

> Having argument labels solves some of the problems that come along with boolean arguments, but "fitImage" is a great example where the false case ("not fit?") doesn't really convey enough information (or can convey misleading information).


-- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160531/8fa6789e/attachment.html>


More information about the swift-evolution mailing list