[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