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 <[email protected]> wrote:
>
> Apologies for using you as a relay...
>
>> Begin forwarded message:
>>
>> From: Charlie Monroe via swift-evolution <[email protected]
>> <mailto:[email protected]>>
>> Subject: Re: [swift-evolution] Ad hoc enums / options
>> Date: May 31, 2016 at 11:43:43 AM MDT
>> To: Charles Constant <[email protected] <mailto:[email protected]>>
>> Cc: Swift Evolution <[email protected]
>> <mailto:[email protected]>>, Christopher Kornher <[email protected]
>> <mailto:[email protected]>>
>> Reply-To: Charlie Monroe <[email protected]
>> <mailto:[email protected]>>
>>
>> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
