[swift-evolution] Ad hoc enums / options
Christopher Kornher
ckornher at me.com
Wed Jun 1 22:05:06 CDT 2016
> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution <swift-evolution at swift.org> wrote:
>
>
> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>> let _ = scaleAndCropImage(image: myImage, toSize: size, operation: .fill)
>>
>> You would not be able to assign `.fill` to a variable and use that for the operation value.
>
> This is my objection to this idea. It does not encourage reuse.
-1For me too. Introducing this quasi-enum would increase cognitive load with little, if any, net benefit. This is the sort of feature that looks great and works wonderfully in example apps, but does not scale well to real systems, where options show up in more methods through time, get passed around to helpers, stored, marshaled into various formats, etc.
As someone mentioned, this would probably be a good fit If Swift adopts a structural type system (I suppose, I have ever used a language with one to my knowledge, unless duck typing counts)
As syntactic sugar for a true enum declaration, it would be a “cool” feature, but reuse would still be problematic.
>
> I would not be able to assign to a variable:
>
> let selectedOperation = .fill
>
> In order to then do this later in the program:
>
> scaleAndCropImage(image: myImage, toSize: size, operation: selectedOperation)
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160601/e58afffc/attachment.html>
More information about the swift-evolution
mailing list