[swift-evolution] Ad hoc enums / options
laurent.mihalkovic at gmail.com
Thu Jun 2 00:48:31 CDT 2016
> On Jun 2, 2016, at 5:05 AM, Christopher Kornher via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution <swift-evolution at swift.org <mailto: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.
there is no reuse problem in the interpretation I propose, and the long/short form names are completely interchangeable.
>> 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 <mailto:swift-evolution at swift.org>
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution