[swift-evolution] Ad hoc enums / options

[Matthew Johnson]

> On May 31, 2016, at 2:04 PM, Erica Sadun <erica at ericasadun.com> wrote:
> 
>> 
>> On May 31, 2016, at 12:35 PM, Matthew Johnson <matthew at anandabits.com <mailto:matthew at anandabits.com>> wrote:
>> 
>> I think I'm -1 on this.  It makes things easier for the implementer of the function and harder for the caller.  
>> 
>> It's not clear whether the caller could store an argument to pass in a variable, but if they could they would need to list out all cases in the type of the variable (unless these anonymous enums have structural subtyping).  This is fragile.  Any time that list changes all variable declarations will have to be updated.
>> 
>> Functions are implemented once and usually called more many times.  It's better for callers if you just write it like this:
>> 
>> enum FitOrFill { case fit, fill }
>> func scaleAndCropImage(
>> image: UIImage,
>> toSize size: CGSize,
>> operation: FitOrFill = .fit
>> ) -> UIImage {
>> 
>> So unless these anonymous enums are structurally subtyped I think it's a bad idea.  And introducing structural subtyping here seems like a pretty large hammer for this use case.
> 
> 
> From the caller's point of view, the type must be inferable and exactly match a token listed in the declaration (which would also appear in Quick Help):
> 
> 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.

If you are not allowing callers to store their argument in a variable then I am 100% opposed to this.  That would the first case in Swift where you *MUST* provide a literal argument when calling a function, and *CANNOT* provide a value you store in a variable (possibly something you receive as an argument from somewhere else).  Why would we want to restrict the flexibility of callers in that way?

> 
> -- E

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160531/64b5dfbe/attachment-0001.html>