Hi Laurent,

Do you have the details of your proposal, I missed it. 

Thanks

> On Jun 2, 2016, at 1:48 AM, L Mihalkovic <laurent.mihalko...@gmail.com> wrote:
> 
> 
>>> On Jun 2, 2016, at 5:05 AM, Christopher Kornher via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>> 
>>> On Jun 1, 2016, at 7:48 PM, Ricardo Parada via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>> On May 31, 2016, at 3:04 PM, Erica Sadun via swift-evolution 
>>> <swift-evolution@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@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to