> On May 31, 2016, at 3:46 PM, Vladimir.S <sva...@gmail.com> wrote:
>
> > 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?
>
> Definitely we *must* be able to use a variable in call to function. The
> problem is how (in case we agreee that the proposed feature could be useful).
>
> I'm thinking about similarity of tuples and this anonymous enums.. If you
> have tuple in function parameter - how would you use variable to pass it to
> function? You'll define a variable of the exact same tuple as required,
> manually, no some separate type provided for this. Yes, if tuple in function
> definition changed - you'll need to change tuple on caller side:
>
> func foo(int: Int, tuple: (Int, String)) {}
>
> foo(1, tuple: (1, "string"))
>
> var tupleVar : (Int, String) = (1, "string")
>
> foo(1, tuple: tupleVar)
>
> So, why not have the same for such anonymous enums?
>
> func foo(int: Int, variant: (.one | .two)) {}
>
> foo(1, variant: .one)
>
> var enumVar : (.one | .two) = .one
>
> foo(1, variant: enumVar)
>
>
> Seems like consistent solution.
It is consistent with tuples, but using a tuple instead of distinct parameters
is usually going to be a bad idea. If we introduce ad-hoc enums people are
going to use it frequently. And options like this are the kind of thing that
*does* change periodically.
Because those changes are usually additive I’m not too concerned about removing
options. But I *am* concerned about re-ordering existing options or adding new
options impacting existing variable declarations. For this reason, these would
need to be order-independent and support structural subtyping. That way my
`(.foo | .bar)` variable is still a valid argument when you change the option
list to `(.baz | .bar | .foo)`.
The existing approach of just defining an enum is really not so bad and removes
this issue altogether. IMO it is a reasonable “workaround” for now.
I believe there is a lot of overlap between doing this the right way and
introducing structural unions like those in Ceylon (fortunately there seems to
be growing support for this). For that reason I think it makes sense to wait
until we have that feature to look at ad-hoc types with enumerated values like
this.
>
>
> On 31.05.2016 22:07, Matthew Johnson via swift-evolution wrote:
>>
>>> On May 31, 2016, at 2:04 PM, Erica Sadun <er...@ericasadun.com
>>> <mailto:er...@ericasadun.com>
>>> <mailto:er...@ericasadun.com <mailto:er...@ericasadun.com>>> wrote:
>>>
>>>>
>>>> On May 31, 2016, at 12:35 PM, Matthew Johnson <matt...@anandabits.com
>>>> <mailto:matt...@anandabits.com>
>>>> <mailto:matt...@anandabits.com <mailto:matt...@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
>>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
