>> 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
