How about this:
Going back to Erica’s original example:
func scaleAndCropImage(
image: UIImage,
toSize size: CGSize,
operation: (.Fit | .Fill) = .Fit
) -> UIImage {
And noting that we are already allowed to declare an enum inside the function,
compiler can generate an enum scoped inside the function named the label of
the enum:
func scaleAndCropImage(
image: UIImage,
toSize size: CGSize,
operation: (.Fit | .Fill) = .Fit
) -> UIImage {
@_exposed num operation {
case Fit
case Fill
}
Then you could declare a var:
var myOperation: scaleAndCropImage.operation = .Fill
Then you can call:
let scaledImage = scaleAndCropImage(image: myImage, toSize: theSize, operation:
myOperation)
@_exposed above would be a compiler private annotation for the auto generated
enum that will make if visible outside of the function. This way the impact is
minimal and such ad hoc enum would be just the same as any other enum. The only
big change in the compiler would be the ability to make some declaration inside
functions visible to the outside code.
> On Jun 3, 2016, at 5:10 PM, Matthew Johnson via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>
> Sent from my iPad
>
>> On Jun 3, 2016, at 6:44 PM, Erica Sadun <er...@ericasadun.com> wrote:
>>
>>
>>> On Jun 3, 2016, at 5:20 PM, Greg Parker via swift-evolution
>>> <swift-evolution@swift.org> wrote:
>>> What about the ABI? This sounds expensive to implement.
>>>
>>> Consider this set of ad-hoc enum types:
>>>
>>> (.a | .b)
>>> (.c | .d)
>>>
>>> Naive implementation: we'll represent these things as ints, with .a=1,
>>> .b=2, .c=1, .d=2.
>>>
>>> The naive implementation breaks when a newly-loaded shared library or some
>>> library evolution adds this type:
>>>
>>> (.a | .b | .c | .d)
>>>
>>> In order to provide ABI stability in the face of arbitrary ad-hoc enum
>>> types we must ensure that every ad-hoc enum value has a globally unique ABI
>>> representation.
>>>
>>> You could constrain ad-hoc enum values to module or class boundaries and
>>> prevent creation of types that use values from different places. For
>>> example, if Foundation defines (.a | .b) then you can't define your own
>>> ad-hoc enum (.a | .b | .c) that is compatible with Foundation's value for
>>> .a. Then the implementation could use ordinary symbols. If usage of ad-hoc
>>> enums is not constrained then ordinary symbols don't work because there is
>>> no universally agreed-upon place where .a is defined.
>>
>> In my mind, the ad hoc enum must be tied to a specific function or method
>> signature. In doing so, it has a unique module/selector associated with it,
>> so it's not just .a but rather Foo.funcname.a (assuming no more than one ad
>> hoc enum per function) or Foo.funcname.3.a (assuming its the third parameter
>> of the selector). The conversation has drifted a bit from my request.
>>
>> If the enum needs to be used in more situations, it needs to be a proper
>> enum because the semantics are tied to a higher level of visibility.
>>
>> I'm striving for enhanced readability in intent (for example, where !x is a
>> poor description of the option other than x, or even when there are >2
>> options that will never be used elsewhere such as fill, fit, scale) and in
>> expression (choosing self-annotating switch statements over if statements,
>> where its clear what each branch intends to do).
>>
>> These enums would be limited to basic hashValue types, and would appear in
>> QuickHelp as annotations of legal values to supply to the argument. My
>> intent is that there never be more than 3-5 enumeration cases used in this
>> anonymous fashion.
>
> Are you still insisting that we not be able to declare a variable holding one
> of these to call the function with later? If so, what is the justification
> for placing a burden on callers that the argument must always be a literal?
> If not, how do you suggest a variable be declared?
>
>>
>> -- 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
