[swift-evolution] Ad hoc enums / options

[Christopher Kornher]

Here is a correction to the equivalent declaration. It would be a RawRepresentable String enum to be compatible with serialization mechanisms e.g. JSON. and other representations. Again, the name could be auto-generated to keep the syntax succinct.

…

would be equivalent to

class MyImage  {
 	enum  ScaleCropFitFill : String {
		case  Fit
		case  Fill
	} 
...


> On May 31, 2016, at 12:25 PM, Christopher Kornher <ckornher at me.com> wrote:
> 
> Apologies for using you as a relay...
> 
>> Begin forwarded message:
>> 
>> From: Charlie Monroe via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>
>> Subject: Re: [swift-evolution] Ad hoc enums / options
>> Date: May 31, 2016 at 11:43:43 AM MDT
>> To: Charles Constant <charles at charlesism.com <mailto:charles at charlesism.com>>
>> Cc: Swift Evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>, Christopher Kornher <ckornher at me.com <mailto:ckornher at me.com>>
>> Reply-To: Charlie Monroe <charlie at charliemonroe.net <mailto:charlie at charliemonroe.net>>
>> 
>> 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.
> 
> 
> 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.
> 
> #2  does add to the length of function declarations, so it is a tradeoff. Perhaps the name could be optional, but...
> 
> #2 would improve debug representations of the value by providing a name that can be found in source code
> 
> In a full-featured metadata system, it would probably be nice to have a type for the enum to simply the handling of all enums. 
> 
> #2 is more future-proof. Systems get more complex over time and one use of a type becomes many. 
> The enum type name (auto-generated or required, it makes no difference) would be scoped to the function’s namespace e.g. (fixing the typo) :
> 
> 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 {…}
> }
> 
> There are two ways that an implementation could evolve from having one use of the enum in a call to multiple uses;
> 
> 1) The function is refactored into more functions internal to the original function’s namespace: module/class/struct/enum.
> 	In this case, it would be appropriate to leave the enum declaration in function declaration to indicate that this is the only public use of the enum.
> 2) More public functions are created that use the enum
> 	In this case, it would be appropriate to declare the enum within the same scope. Existing code would not be affected. Smart editors could provide this refactoring.
> 
> - Chris K

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