Anyone thinking about complexity????
> On Jun 4, 2016, at 4:58 PM, Hooman Mehr via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> 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
>> 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
