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.
Sent from my iPad
> On May 31, 2016, at 12:44 PM, Tony Allevato via swift-evolution
> <[email protected]> wrote:
>
> Big +1. I had similar thoughts a while back when I was writing some C++ or
> Java code that had boolean arguments, and I found myself hating how
> non-documenting they were and I would contrive two-valued enums to make call
> sites look better. Having a crisp clean syntax for this would be fantastic
> and encourage people to write self-documenting APIs.
>
> 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).
>
>
>> On Tue, May 31, 2016 at 9:17 AM Erica Sadun via swift-evolution
>> <[email protected]> wrote:
>> Here's a function signature from some code from today:
>>
>> func scaleAndCropImage(
>> image: UIImage,
>> toSize size: CGSize,
>> fitImage: Bool = true
>> ) -> UIImage {
>>
>>
>> And here's what I want the function signature to actually look like:
>>
>> func scaleAndCropImage(
>> image: UIImage,
>> toSize size: CGSize,
>> operation: (.Fit | .Fill) = .Fit
>> ) -> UIImage {
>>
>>
>> where I don't have to establish a separate enumeration to include ad-hoc
>> enumeration-like semantics for the call. A while back, Yong hee Lee
>> introduced anonymous enumerations (and the possibility of anonymous option
>> flags) but the discussion rather died.
>>
>> I'm bringing it up again to see whether there is any general interest in
>> pursuing this further as I think the second example is more readable,
>> appropriate, and Swifty than the first, provides better semantics, and is
>> more self documenting.
>>
>> Thanks for your feedback,
>>
>> -- Erica
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
